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ABSTRACT 


The  major  purpose  of  this  study  was  to  determine  tie  effect  on 
system  design  of  using  manpower  and  personnel  resources  data  as 
design  requirements.  Secondary  objectives  were  to  determine  under 
what  conditions  and  in  what  form  these  data  should  be  used  to  have 
maximum  effect  on  design.  Equipment,  manpower  data  (e.g.  ,  quanti¬ 
ties  and  SKill  levels),  and  personnel  resources  data  (PRD)  inmits 
(e.g.  ,  task  information)  which  were  produced  during  the  development 
of  the  Titan  III  propellant  transfer  and  pressurization  subsystem  were 
adopted  and  presented  incrementally  to  six  design  engineers  to  simu¬ 
late  the  Air  Force  phase  1A/1B  development  of  that  subsystem. 
Subjects  were  required  to  create  schematics,  equipment  descriptions 
and  drawings,  control  panel  layouts,  operating  procedures  and  bills 
of  material.^  Cost-effectiveness  measures  including  equipment  cost, 
equipment  reliability,  human  reliability,  system  safety  and  design 
adequacy  were  applied  to  the  data.  It  was  found  that  manpower  re¬ 
quirements  and  PRD  inputs  do  influence  the  equipment  configuration, 
but  in  this  study  only  moderately,  because  the  equipment  design 
proceeded  so  rapidly  that  incremental  PRD  inputs  inevitably  lagged 
the  design.  Engineers  were  responsive  only  to  inputs  which  are 
framed  as  design  requirements  and  which  were  interpreted  in  design¬ 
relevant  terms.  Confirming  the  results  of  previous  studies,  engineers 
were  found  to  be  generally  unaware  of  or  indifferent  to  personnel 
considerations.  Different  engineers  interpreted  the  same  design 
requirements  and  assigned  priority  to  deeigu  criteria  differently. 

The  engineers  relied  heavily  on  experience  and  stereotyped  solutions 
for  design  answers.  The  results  of  the  study  indicate  that,  if  man¬ 
power  and  personnel  resources  data  are  to  be  incorporated  into  design, 
it  is  necessary  to  supply  these  inputs  to  the  engineer  as  design 
requirements  in  his  initial  statement  of  work.  Consequently,  funda¬ 
mental  manpower  and  personnel  analyses  must  be  performed  prior 
to  the  issuance  of  a  Request  for  Proposal  (RFP)  and  not  delegated  to 
the  development  contractor.  The  contractor  must  he  required  to 
design  to  a  detailed  manning  structure  which  is  specified  in  his  state¬ 
ment  of  work.  Further  recommendations  are  supplied  which  suggest 
ways  in  which  Air  Force  management  of  the  personnel  subsystem 
program  should  be  revised. 
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GLOSSARY 


Air  Force  Specialty  (AFS) 

A  grouping  of  duties  and  tasks  related  in  ekill,  knowledge,  difficulty, 
operational  sequence,  and  the  like,  and  making  up  a  job  or  specialty. 

Design  Input  Tests  (PIT) 

Design  Input  Tests  require  the  subject  to  analyze  an  individual 
input  directly  rather  than  integrate  the  input  into  an  overall  design 
as  required  in  the  D^T.  (Sessions  9-10  of  the  present  test  series 
were  modeled  after  the  DIT. ) 

Design  Product  Tests  (DPT) 

Design  Product  Tests  in  which  the  solutions  to  the  problem  was  the 
actual  completion  of  the  design  task;  the  actual  designing  of  a  system 
to  satisfy  the  problem  inputs  or  requirements.  This  type  of  test 
examines  design  "longitudinally,"  that  is,  the  entire  process  from 
assignment  of  the  problem  to  its  completion.  (The  first  eight  sessions 
of  the  experimental  portion  of  this  study  were  modeled  after  the  DPT 
type  of  situation. ) 

Personnel  Equipment  Data  (PEP) 


An  element  of  the  Personnel  Subsystem  which  is  made  up  of  the 
analytical  data,  in  tne  form  of  task  and  equipment  information  that 
describes  the  nature  and  interrelationships  of  functions  performed 
by  system  personnel  and  system  hardware. 

Pe raonnel  Resources  Data  (PRD) 


Personnel  Resources  Data  is  defined  as  the  data  which  implements 
or  interprets  a  specific  personnel  requirement. 

Qualitative  and  Quantitative  Personnel  Requirements  Information  (QQPRI) 


QQPRI  is  composed  of  data  describing  the  quantitative  requirements, 
qualitative  requirements,  training  requirements  and  prerequisites  for 
the  personnel  required  to  operate,  maintain,  and  command  a  given 
system.  This  data  are  used  in  planning  for  system  personnel,  training 
and  manpower. 
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Requirements  Allocation  Sheets  (RAS) 


Requirements  Allocation  Sheets  (RAS)  are  a  form  of  system  design 
documentation  upon  which  are  identified  the  design  requirements  for 
specific  operations,  maintenance,  test  and  activation  functions. 


SECTION  I 


INTRODUCTION 


NATURE  OF  THE  PROBLEM 

The  Importance  of  Human  Factors  in  System  Design 

The  importance  of  human  factors  to  system  performance  has 
been  shown  a  number  of  times.  Both  logically  and  empirically, 
the  negative  effect  of  inadequate  consideration  of  the  human 
element  during  design  can  be  demonstrated  The  contribution  of 
human  error  to  the  unreliability  of  overall  system  performance 
has  been  graphically  illustrated  by  Meister  and  Rabideau  (1965, 
Figure  1-1)  and  empirically  by  Meister  (1967).  In  the  latter 
study,  approximately  24%  of  overall  system  unreliability  could 
be  attributed  to  the  effect  of  human  error.  In  1960,  Shapero 
et  al.  reported  on  a  survey  of  several  major  missile  systems 
and  reported  that  the  percentage  of  equipment  failures  caused 
by  human  error  ranged  from  20%  to  53%  of  the  total  failures 
reported.  Willis  (1962)  estimates  "that  40%  of  the  problems 
uncovered  in  missile  testing  derive  from  the  human  element. 

63.6%  of  the  (shipboard)  collisions,  flooding  and  grounding 
could  be  blamed  upon  human  error.  Reports  produced  by  the 
United  States  Air  Force  indicate  that  human  error  was  respons¬ 
ible  for  234  of  313  aircraft  accidents  during  1961"  (p.  1). 

A  second  area  of  concern  is  that  of  the  cost  of  the  system, 
which  is  defined  today  in  terms  of  life-cycle  costs.  The  evidence 
is  accumulating  that  the  cost  of  the  personnel  to  operate  and 
maintain  a  system  throughout  its  useful  life  is  equal  to  or  ex¬ 
ceeds  those  of  the  hardware.  Thus,  we  have  a  double-edged 
problem,  performance  decrement  and  high  costs,  which  can  be 
related  to  the  human  element  of  the  system. 

This  problem  hat  been  made  more  severe  by  a  history  of 
development  of  new  systems  with  emphasis  primarily  on  the 
design  of  hardware  and  with  little  or  no  regard  for  the  capability  or 
cost  of  the  personnel  that  will  be  available  to  support  the  system. 

It  has  been  advocated  that  one  way  to  reduce  the  problem  is  to 
develop  systems  with  human  factors  data  included  as  design 
requirements.  To  this  end,  the  Air  Force  put  into  practice  10 
years  ago  what  has  come  to  be  known  as  the  Personnel  Subsystem 
Concept.  The  Personnel  Subsystem  is  defined  (AFR  30-8,  USAF, 
n.d.  )  as  "that  major  functional  part  of  a  system  which,  through 
effective  implementation  of  its  various  elements,  provides  the 
human  performance  necessary  to  operate,  maintain  and  control 
the  system  and  its  intended  operational  environment.  " 
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"The  major  objectives  of  the  Personnel  Subsystem  program  are: 

(a)  to  promote  the  acquisition  of  functionally  integrated  systems  and 
facilities  which  can  be  safely  and  reliably  operated,  maintained, 
and  supported  by  USAF  personnel;  (b )  to  provide  appropriate 
agencies  with  timely  planning  and  technical  information  concerning 
personnel,  training,  and  life  support  requirements  which  systems 
will  impose  on  the  Air  Force  structure;  and  (c)  to  insure  timely 
development  and  acquisition  of  training  equipment,  facilities,  and 
protective  equipment  for  the  support  of  system  personnel.  To 
accomplish  these  objectives,  the  FS  effort  embraces  virtually  all 
the  considerations  of  man  in  the  system,  whether  these  involve 
the  application  of  human  engineering  principles  to  the  design  of 
the  operational  hardware,  the  selection  and  development  of  train- 
ing  equipment,  or  the  preparation  of  informational  job  aids  intended 
to  assist  personnel  in  carrying  out  their  assigned  tasks.  "  (AFSCM 
80-3,  USAF,  1963) 

Despite  this,  and  despite  very  intensive  missionary  efforts  by 
human  factors  specialists  and  governmental  managers,  it  is 
almost  a  truism  that  human  factors  specialists,  working  on  system 
development  projects,  experience  grave  difficulty  in  making 
effective  inputs  to  that  development.  Thus  system  failures  resulting 
from  human  error  continue  high  and  system  manpower  costs  con¬ 
tinue  to  grow  at  an  accelerating  rate.  Why  do  these  conditions 
continue  to  exist?  The  answer  is  obvious  to  those  experienced  with 
the  system  development  process.  It  is  the  fact  that  human  factors 
specialists  are  brought  in  late  to  system  development  projects 
after  basic  design  concepts  are  developed,  concepts  which  reflect 
only  superficially  any  consideration  of  personnel  factors.  Thus 
the  human  factors  data  which  should  be  incorporated  in  system 
design  to  achieve  an  optimal,  more  cost/effective  system  are  too 
late  to  have  an  impact  on  design.  To  make  matters  worse,  many 
of  these  human  factors  inputs  are  regarded  by  design  engineers  as 
so  much  paper  work  and  rejected  out  of  hand.  The  lowest  priority 
in  design  analysis  is  given  to  criteria  dealing  with  personnel  aspects 
(This  is  not  to  say  that  human  factors  data  are  completely  ignored; 
they  play  a  role  obviously  in  such  PS  aspects  as  the  development  of 
training  curricula.  ) 

All  of  these  condition®  routinely  exist  in  almost  every  system 
development  project  (except  those  fortunate  few  like  the  NASA  man 
ir.-space  flight  program)  despite  very  large  sums  of  money  expended 
for  proper  implementation  of  the  personnel  subsystem. 

What  can  be  done  to  improve  the  situation ?  The  answer  can  only  be 
determined  by  an  examination  of  the  deuign/developmcnt  process 
itself  and  by  an  evaluation  of  the  usefulness  of  the  various  human 
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factors  data  and  analyses  to  that  process.  Those  data  and  analyses 
which  are  ineffective  should  be  discarded;  those  which  are  only 
marginally  effective  should  be  modified  to  improve  their  utility; 
those  which  appear  to  have  the  greatest  potential  for  influencing 
design  should  be  emphasized. 

This  study  is,  therefore,  directed  toward  a  controlled  examina¬ 
tion  of  the  utility  of  PRD  in  system  design  and  to  the  determination 
of  the  conditions  under  which  PRD  can  be  effective  in  influencing 
that  design. 

Manpower  Requirements  and  Personnel  Resources  Data 


The  data  and  analyses  selected  as  the  focus  of  this  study  were 
those  descriptive  of  the  quantity  and  skill  capibility  of  the  personnel 
required  for  a  system.  Rationally,  if  see  me  1  that  these  kinds  of 
inputs  used  as  design  requirements  could  have  an  effect  on  the 
system  configuration.  These  data  have  been  termed  Manpower 
Requirements  (MR)  and  Personnel  Resources  Data  (PRD).  MR 
were  defined  as  those  data  which  prescribe  thv  quantity  and  quality 
of  personnel  comprising  the  crew,  and  PRD  were  defined  as  that 
information  which  implemented  or  interpreted  the  Manpower  Require¬ 
ments  for  the  designer,  e,  g.  ,  list  of  tasks,  task  time  capability, 
task  human  error  rate  probability.  Table  HI,  page  26,  further 
describes  these  data. 

It  was  assumed  that  manpower  requirements  can  be  quantitatively 
and  precisely  derived  from  early  analysis  of  mission/system  re¬ 
quirements,  before  equipment  development  begins.  Hence,  man¬ 
power  requirements  with  their  supportive  personnel  resources  data 
can  be  made  available  to  the  design  engineer  at  the  same  time  he 
begins  design  of  the  system. 

The  Potential  Effect  of  Manpower  Data  Upon  System  Design  Can  Be 
Logically  Demonstrated  ~  ~ 

If  the  number  of  personnel  available  to  crew  a  subsystem  under 
development  is  increased  or  decreased  by  a  factor  of  2,  it  seems 
reasonable  that  the  subsystem  design  would  be  substantially  modi¬ 
fied  to  accommodate  the  change  in  personnel.  The  same  should 
apply  to  a  change  in  skill  level,  as  between  highly  trained,  well 
experienced  personnel  and  apprentices  who  have  received  only 
basic  training. 

Can  this  effect  be  empirically  demonstrated,  however’  Does 
the  designer  react  to  the  imposition  of  a  manpower  requirement 
by  a  change  in  design  which  reflects  at  the  very  least  his  attempt 
to  satisfy  that  requirement’  One  of  the  goals  of  the  study  was  to 


determine  the  conditions  under  which  manpower  requirements 
(apart  from  its  implementation  data)  can  most  influence  the  sub¬ 
system  configuration. 

It  is  possible,  for  example,  that  the  consequences  of  such 
requirements  are  not  sufficiently  apparent  to  the  system  designer. 

If  one  were  to  specify  that  for  one  design  all  operators  will  be 
approximately  6  feet  4  inches  in  height,  and  for  another  the  maximum 
operator  height  will  be  3-1/2  feat,  it  is  apparent  that  equipment 
configuration  will  be  materially  affected  (or  if  it  is  not  affected, 
performance  decrement  will  be  high).  Indeed,  where  requirements 
are  so  extreme,  it  is  likely  that  the  designer  will  not  need  the 
prompting  of  the  human  factors  specialist  to  cause  him  to  include 
those  requirements  in  his  design. 

But  how  does  the  designer  cope  with  a  manpower  requirement 
that  he  design  for  a  subsystem  which  will  be  operated  and  main¬ 
tained  by  personnel  between  the  5th  and  95th  percentiles  (e.  g.  , 
personnel  with  three-  and  five-level  skill  designations)? 

PRD  as  Communicated  Information 

Before  exploring  the  potential  reasons  for  the  lack  of  effectiveness 
of  PRD  in  Influencing  design,  it  is  necessary  to  place  the  former  in 
a  conceptual  framework.  PRD  inputs  are  communicated  information. 
Hence  the  format  in  which  that  information  is  communicated,  its 
timing  relative  to  other  events  in  the  developmental  process,  the 
number  of  other  inputs  with  which  it  competes  and  its  clarity  to  the 
recipient  of  the  information  (the  design  engineer)  will  all  affect  the. 
acceptance  of  the  message  and  its  utility  to  the  designer.  No  matter 
how  intrinsically  meaningful  the  data  presented,  if  those  data  are 
difficult  to  interpret  in  design  terms,  or  are  presented  at  the  incor¬ 
rect  time,  etc.  ,  the  effectiveness  of  the  data  will  be  reduced. 

Reasons  for  Ineffective  PRD 

Assuming,  therefore,  that  personnel  requirements  have  the 
capability  of  influencing  hardware  design,  the  possible  reasons  why 
the  PAD  inputs  implementing  these  requirements  fail  to  produce 
the  desired  impact  fall  into  the  following  categories: 
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(1)  Inappropriate  Timing.  Many  PRD  inputs  tend  to  lag  §ign;acant 
"design  decisions  rather  than  to  anticipate  them.  In  fact,  even 
to  be  concurrent  with  these  decisions  is  to  be  too  Late.  The 
average  human  factors  specialist,  who  often  lacks  all  but  a 
minimal  engineering  background --if  that- -finds  himself 
heavily  dependent  upon  the  flow  of  engineering  information  to 
him  as  the  basis  for  his  contributions  to  design.  Consequently, 
he  fails  to  participate  in  the  preparatory  work  which  results 

in  terminal  design  decisions.  However,  it  is  precisely  in  this 
preparatory  phase  that  fundamental  decisions  are  made  which 
become  extremely  difficult  to  reverse. 

Attention  must  also  be  directed  to  the  relatively  informal 
character  of  the  analyses  leading  to  basic  design  decisions. 
Formal  paper  work  tends  merely  to  describe  decisions  that 
have  already  been  made  informally.  The  utility  of  formal 
PRD  inputs  (as  differentiated  from  informal  directly  expressed 
verbal  inputs),  therefore,  tends  to  be  reduced.  If  formal  in¬ 
puts  are  made,  they  must  be  made  in  advance  of  the  formal 
decisions  or  they  will  not  be  considered. 

The  implications  of  inappropriate  timing  should,  it  was  felt, 
be  one  of  the  factors  examined  in  the  proposed  study.  If  the 
utility  to  the  designer  of  the  PRD  input  can  be  significantly 
improved  by  improving  its  timing  relative  to  major  system 
development  milestone,  then  appropriate  solutions  to  this  prob¬ 
lem  could  be  recommended. 

(2)  Inadequately  Expressed  Implications.  It  must  be  presumed  that 
each  human  factors  datum  has  some  implications  for  the  design 
configuration;  but  in  many,  if  not  most,  PRD  inputs,  these  im¬ 
plications  are  not  expressed.  It  is,  for  example,  no  use  to 
tell  the  system  designer  merely  that  the  personnel  who  will 
man  his  system  will  have  a  five -level  skill.  It  is  necessary 

to  tell  him,  in  addition,  what  this  datum  implies  for  his  design 
or  what  he  should  do  in  concrete  equipment  terms  to  account 
for  that  skill  level.  Without  this  additional  information,  the 
design  engineer  is  lost.  It  is,  therefore,  a  reasonable  hypo¬ 
thesis  that  the  utility  and  acceptability  of  PRD  inputs  would  be 
much  increased  if  greater  attention  were  paid  to  describing 
the  design  consequences  of  PRD. 

(3)  Inappropriate  Designer  Attitudes.  The  whole  problem  is  com- 
pllcaied^by  the  fact  that,  according  to  the  results  of  previous 
studies  of  human  factors  information  utilisation  by  designers 
(Meister  and  Farr,  1966,  Me  isle  r  and  Sullivan,  1967),  de¬ 
signers  accord  behavioral  inputs  a  rather  low  priority  in  the 
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scheme  of  things.  (The  studies  cited,  which  have  significant 
interrelationships  with  the  present  one,  will  be  discussed  in 
some  detail  later.  )  Although  he  would- -and  does  - -protest 
the  contrary,  the  designer  has  an  acquired  bias  against  PRD 
inputs,  and  thus  the  clarity  of  the  information  presented  must 
be  intensified  if  it  is  to  breach  this  barrier.  These  difficul¬ 
ties  are  intensified  because  system  development  is  often 
chaotic  and  characteristically  behind  schedule.  The  designer 
is  beset  with  a  host  of  data  inputs,  each  competing  with  the 
other;  hence,  the  human  factors  message  must  be  louder  than 
would  otherwise  be  required  if  it  is  to  receive  a  hearing. 

Factors  to  be  Examined 

It  is  apparent,  therefore,  that  in  any  investigation  of  the  effective¬ 
ness  with  which  manpower  requirements  and  personnel  resources  data 
inputs  are  utilized  in  system  development,  the  following  factors  must 
be  examined: 

(1)  The  manner  in  which  the  engineer  ordinarily  designs,  because 
FRB  inputs  must  fit  into  that  process; 

(2)  The  format  or  manner  in  which  PRD  inputs  are  supplied  to 
design  engineers; 

(3)  The  timing  or  sequence  with  which  PRD  inputs  are  provided; 

(4)  The  design-relevancy  of  the  data  supplied  in  PRD  inputs; 

(5)  The  effect  of  manpower  requirements  as  requirements  on 
hardware  design  concepts; 

(6)  The  availability  of  information  as  a  whole  to  the  engineer 
during  the  design  process; 


(7)  The  engineer's  attitude  toward  the  personnel  aspects  of  the 
system  and  to  human  factors  data  as  inputs  to  design. 


B.  PREVIOUS  RELEVANT  RESEARCH 


Research  Relevancy 

A  discussion  of  all  the  research  which  has  been  published  on  the 
general  subject  of  manpower,  personnel  requirements  and  PRD  is 
beyond  the  scope  of  this  report  and  would  in  any  event  be  irrelevant 
to  the  questions  raised  in  Section  A.  (For  those  interested  in  a 
general  review  of  che  available  literature,  it  is  suggested  that  they 
read  the  following  reports:  Powell  (1963),  Hannah  (1965). 

The  irrelevancy  of  most  of  this  literature  results  from  the 
unfortunate  fact  that,  although  great  attention  has  been  paid  to  the 
mechanics  of  PRD  development,  research  on  PRD  usefulness, 
particularly  to  the  design  engineer,  is  practically  nil. 

With  the  exception  of  two  studies  performed  by  Meister  and  Farr 
(1966)  and  Meister  and  Sullivan  (1967),  which  will  be  discussed  in 
detail  below,  research  has  not  addressed  itself  to  the  practical 
utility  and  effectiveness  of  human  factors  inputs  within  the  design 
process.  It  is--or  should  be- -characteristic  of  any  empirical 
discipline  that  its  techniques,  data  and  theories  are  constantly 
under  examination  and  revision  to  bring  them  into  accord  with 
reality.  Human  factors  inputs  should  also  be  subjected  to  the  same 
kind  of  reality- testing.  Unfortunately,  however,  with  the  exception 
of  the  two  studies  cited  above,  there  has  been  very  little,  if  any, 
validation  of  human  factors  tools. 

There  are  two  reasons  for  examining  these  studies  in  some  de¬ 
tail.  First,  because  the  general  research  strategy  employed  in 
these  studies  was  also  used  in  the  present  investigation.  Second, 
the  results  achieved  in  the  present  study  are  much  more  under¬ 
standable  if  viewed  in  the  light  of  the  previous  research. 

Previous  Research  Goals 


The  specific  goals  of  the  two  studies  which  are  relevant  to  the 
present  investigation  were  to  answer  the  following  questions: 

(1)  What  kind  of  information  does  the  designer  use  as  the  basis 
of  his  design  decisions  an  1  what  kinds  of  analyses  does  he 
make  of  design  problems’ 

(l)  How  efficiently  does  the  designer  utilize  particular  human 
factors  inputs  and  what  design  implications  does  he  draw 
from  these  inputs’ 
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(3)  In  what  form  will  fhese  inputr  have  their  greatest  effect? 

(4)  What  are  the  design  engineer's  attitudes  tow?'  d  human 
factors  personnel,  human  factors  information  and  the  role 
of  the  operator  in  design? 

(5)  To  what  extent  does  he  routinely  include  human  factors  in 
his  design  analyses? 

In  contrast  to  the  present  research,  the  two  studies  dealt  with 
human  engineering  data  inputs  of  the  "knobs  and  dials"  type,  that 
is,  those  inputs  which  are  most  directly  relevant  to  the  character¬ 
istics  of  the  equipment. 

Research  Strategy 

The  general  philosophy  underlying  the  approach  in  these  studies 
assumes  the  following: 

How  engineers  analyze  their  design  problems  determines  how  they 
use  human  factors  information  and  the  manner  in  which  operator  con¬ 
siderations  are  incorporated  into  design.  In  other  words,  informa¬ 
tion  has  value  to  the  engineer  only  to  the  extent  that  he  can  relate 
it  to  his  design  task. 

Consequently,  in  order  to  secure  data  about  the  usefulness  of 
human  factors  inputs  to  design,  it  is  necessary  to  place  the  engineer 
in  a  situation  which  requires  him  to  design  and  in  which  the  inputs 
provided  can  be  (if  useful)  related  to  the  design  task. 

Thus,  it  is  no  good  asking  designers  to  verbalize  their  design 
methodology,  to  ask  them,  baldly,  how  do  you  go  about  designing? 
Much  of  their  methodology  is  covert;  the  engineer  may  even  be 
unaware  of  the  essential  creative  processes  he  employs.  In  addition, 
the  engineer  is  not  overly  verbal. 

Consequently,  a  formal  interview/questionnaire  methodology  was 
rejected,  as  well  as  any  technique  which  was  not  based  on,  or  could 
not  be  incorporated  into,  concrete  design  situations.  The  method 
followed  was,  therefore,  to  (1)  present  the  engineer  with  a  series 
of  realistic  design  problems  (representative  of  those  he  ordinarily 
encountered),  (2)  provide  him  with  informational  inputs  related  to 
these  pro*  lems.  (3)  require  him  to  solve  the  problems,  (4)  observe 
how  (or  if)  he  used  the  inputs  in  the  problem  solution,  (5)  and  then, 
following  problem  solution,  review  with  the  engineer  how  he  achieved 
that  solution  and  the  value  of  the  inputs  provided. 
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Type*  of  Teat  Situation* 


Two  type*  of  teat  fituationa  were  developed.  The  rationale  for 
theae  teat  situations  waa  aa  follow*: 

Any  individual  design  problem  will  (if  it  ia  to  be  realiatic)  re¬ 
quire  only  a  limited  number  and  type  of  human  factor*  input*.  Thu*, 
for  example,  a  conaole  deaign  may  require  consideration  of  anthro¬ 
pometric  requirement*  but  not  communications;  or  consideration  of 
meter  size*,  but  not  maintenance  test  points.  Consequently,  it  ia 
impracticable  to  develop  a  complete  range  of  fully  articulated  deaign 
problems  in  any  one  test  situation. 

The  two  type*  of  deaign  t-sata  developed  were: 

(1)  The  Design  Product  Teat  (DPT),  in  which  the  deaign  solution 
or  product  was  the  actual  layout  of  an  equipment  to  satisfy  the 
problem  inputs  or  requirements.  This  situation  studied  design 
"longitudinally,"  that  is,  the  entire  process  from  assignment 
of  the  problem  to  its  completion.  (Parts  of  the  experimental 
methodology  of  the  present  research  were  modeled  after  the 
DPT  type  of  situation.  ) 

For  example,  one  DPT  required  the  layout  of  a  command/control 
station  aboard  a  missile  frigate.  Another  required  the  sketch  of 
a  self-contained  portable  test  set  for  circuit  modules  (printed 
circuit  cards).  Design  requirements  for  these  equipments  were 
described  in  terms  of  a  design  specification  format  commonly 
used  in  Department  oi  Defense  military  procurement,  e.  g.  , 
applicable  specifications,  performance,  operability,  reliability 
and  maintainability  requirements,  use  of  standard  and  commer¬ 
cial  parts,  etc. 

The  deaign  required  for  the  DPT  was  that  of  a  "conceptual  sketch," 
something  between  an  artist's  rendering  and  a  fully  detailed 
design.  Such  a  drawing  is  often  made  for  an  initial  design  analysis 
such  as  might  be  required  in  responding  to  a  Request  for  Proposal 
or  in  the  very  early  stages  of  conceptual  system  definition. 

(<i)  The  Design  Input  Test  (EXT),  in  which  an  equipment  layout  was 
not  required  of  the  designer,  but  in  which  he  had  to  analyse  the 
individual  input  directly.  These  "cross  sectional"  situations 
particularly  emphasized  the  analytic  inferences  to  be  drawn 
from  the  design  problem.  (Another  part  of  the  experimental 
methodology  of  the  present  study  was  modeled  after  the  D!T,  ) 
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As  an  example  of  a  DIT  test  item,  the  designer  might  be  presented 
with  the  problem  of  designing  a  shipboard  equipment  and  asked  to  list 
the  human  engineering  inputs  he  would  need  to  solve  the  problem.  DIT 
situations  were  necessarily  somewhat  more  abstract  than  those  of  the 
DPT,  because  they  dealt  with  methodology  that  would  or  should  be 
adopted,  rather  than  the  completed  product  of  that  methodology,  i.  e. , 
a  drawing. 

The  difference  between  these  two  test  situations  was  one  of  degree 
only;  in  each  case  a  design  problem  was  explicitly  or  implicitly  presented, 
but  in  the  first  the  focus  of  interest  was  the  design  output,  whereas  in 
the  second  interest  lay  in  the  designer's  direct  response  to  input  charac¬ 
teristics. 

It  is  important  to  note  that  the  tests  were  so  developed  that  they 
demanded  analysis  of  operator  factors  if  the  designs  were  to  be  optimal. 

In  other  words,  the  production  of  responses  involving  analysis  of  opera¬ 
tor  considerations  was  not  merely  incident"'.  to  these  designs,  but  were 
an  integral  requirement.  For  example,  the  design  specification  for  DPT 
I  required  that  a  decision  be  made  between  single  vs.  multi -operator  use 
of  the  equipment,  a  decision  which  would  have  significant  implications 
for  design. 

It  was  essential  that  these  test  problems  be  highly  realistic,  since 
designers  tend  to  react  negatively  to  situations  in  which  technical  details 
are  incorrect  or  inappropriate.  To  ensure  the  necessary  degree  of 
realism,  highly  experienced  senior  design  personnel  reviewed  the  tests 
and  made  any  required  modifications  before  the  tests  were  presented  to 
subjects.  (This  procedure  was  followed  in  the  present  study  as  well. ) 

Test  Atmosphere 

Each  test  required  4  hours  (a  pretest  had  indicated  that  this  length 
of  time  was  sufficient  to  elicit  the  desired  responses),  and  there  was  a 
week's  hiatus  between  each  test.  The  tests  were  admin  stered  individ¬ 
ually, 

A  highly  informal  atmosphere  was  encouraged.  During  the  typt  test 
period,  the  designer  was  entirely  free  to  respond  as  hz  wished,  even  to 
the  point  of  leaving  the  test  area  if  he  wished.  He  had  available  to  him  a 
standard  drawing  board,  drawing  equipment,  copies  of  all  military 
specifications  noted  as  applicable  in  the  design  problem  statement,  as 
well  as  other  human  factors,  reliability  and  maintainability  handbooks 
which  are  considered  "standard"  texts  in  these  fields.  The  designer 
was  informed  that  he  would  be  observed  during  the  session,  but  that 
he  was  free  either  to  ignore  the  observer  or  to  interact  with  him  as  he 
wished.  A  tape  recorder  was  provided  to  record  the  designer's  verbal 
responses. 
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During  the  DIT,  the  investigator  interacted  directly  with  the  subject, 
and  the  test  items  can  be  considered  as  a  specialized  type  of  interview 
schedule.  DIT  responses  were  recorded  primarily  on  tape  recorder 
with  some  written  responses  required  (where  lists  of  alternative  responses 
had  to  be  ranked).  Because  of  the  unstructured  nature  of  the  interview 
probes,  the  test  situations  can  be  considered  as  having  an  almost  clinical 
atmosphere. 

The  debriefing  following  the  engineer's  completion  of  the  design  and 
during  the  DIT  was  extremely  "loose."  Although  a  series  of  standard 
questions  was  asked  by  the  investigator1,  the  subject's  responses  were 
followed  up  to  secure  greater  detail,  so  that  in  effect  the  engineer 
determined  where  the  discussion  led.  At  the  same  time,  the  investigator 
did  not  content  himself  with  the  initial  response  to  a  question,  but  con¬ 
tinued  to  probe  intensively,  requiring  the  subject  to  explain  his  answers 
in  more  detail,  until  the  subject' s  ability  to  respond  was  exhausted.  This 
procedure  was  followed  to  get  beyond  any  relatively  stereotyped  response 
patterns  the  engineer  might  have.  Discussions  were  sufficiently  probing 
that  a  few  subjects  became  somewhat  emotional  in  their  replies. 


Sample  questions  included: 

(1)  Did  the  specification  contain  enough  information  for  you  to 
design  what  you  would  consider  a  satisfactory  control  panel? 

(2)  Did  it  lack  any  information  that  you  felt  you  needed?  If  so, 
what  was  lacking? 

(3)  What  would  you  consider  to  be  the  major  problems  you  had  in 
designing  this  equipment? 

(4)  What  factors  (design  parameters)  did  you  consider  most  im¬ 
portant  in  designing  this  equipment? 

These  questions  were  considered  only  as  models.  The  investigator 
was  free  to  modify  them  in  terms  of  the  sequence  and  content  of  the  sub¬ 
ject's  responses.  In  particular,  the  subject  was  asked  to  explain  each 
design  behavior  observed.  Emphasis  was  placed  on  the  reason  why  a 
particular  design  action  was  taken.  (Example:  I  see  that  you  located 
this  bank  of  toggle  switches  at  the  extreme  lower  left  of  your  control 
panel.  Can  you  tell  me  why  you  located  them  in  that  position?) 
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The  same  procedures  were  employed  in  the  present  test  series. 

Subjects 

Subjects  in  the  first  study  (Meister  and  Farr,  1966)  were  20  design 
engineers,  including  three  design  managers  (differentiated  from  their 
colleagues  by  greater  breadth  of  experience  and  responsibility).  These 
subjects  were  selected  from  the  Product  Design  and  Services  Department 
of  The  Bunker-Ramo  Corporation  (BRC).  This  is  the  department  whose 
design  responsibilities  would  ordinarily  involve  human  factors  consider¬ 
ations  most  heavily,  since  these  responsibilities  include  t**e  design  of 
control  panels,  the  external  chassis  of  the  equipment,  the  packaging  of 
the  total  equipment  for  maintainability,  etc.  The  engineering  responsi¬ 
bilities  these  subjects  had  were  largely  confined  to  detail  design;  in 
other  words,  although  they  made  design  decisions,  these  decisions  were 
on  a  detail  level. 

The  subjects  selected  were  those  who  had  had  a  reasonable  amount  of 
experience  in  actually  designing  equipment.  Draftsmen  and  junior  engi¬ 
neers,  who  had  responsibility  for  providing  only  the  details  of  a  drawing 
after  the  basic  concept  had  been  provided  by  others,  were  excluded. 

The  median  amount  of  subject  experience  was  14  years.  However, 
only  half  of  the  subjects  had  a  bachelor's  degree  in  engineering  or  the 
equivalent  in  course  credits. 

Subjects  in  the  sec  >nd  study  (Meister  and  Sullivan,  1967)  were  10 
design  engineers  from  the  McDonnell -Douglas  Aircraft  (DAC)  Division. 
Their  range  of  specialization  was  substantially  broader  than  the  BRC 
subjects,  including  crew  accommodations,  cockpit  design,  controls  and 
displays,  escape  systems,  life  support  systems,  interiors,  etc. 

These  subjects  represented  a  more  sophisticated  and  experienced 
population  than  the  BRC  group;  this  sophistication  and  experience  were 
reflected  in  their  responses  to  the  design  problems. 

Median  years  of  experience  were  15,  about  the  same  as  the  BRC 
group.  However,  all  but  two  of  the  DAC  subjects  had  their  engineering 
degrees,  whereas  only  half  of  the  BRC  sample  had  degrees  or  their 
equivalent.  All  of  the  DAC  subjects  were  what  one  could  categorize  as 
"lead  engineers.  " 

In  summary,  therefore,  30  design  engineers,  with  varied  experience 
and  education  working  in  two  industrial  environments,  were  tested  on  a 
variety  of  human  engineering  inputs  for  a  total  of  approximately  360  hours. 
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Findings 


The  principal  findings  of  the  two  studies  which  are  relevant  to  the 
present  investigation  can  be  summarized  as  follows: 

(1)  Design  engineers  have  little  or  no  ‘uterest  in  human  factors 
and  characteristically  fail  to  employ  human  factors  criteria 
in  their  designs. 

(2)  Design  analysis  is  largely  determined  by  constraints  and  exper¬ 
imental  stereotypes. 

(3)  The  most  important  source  of  information  for  the  designer  is 
the  design  specification  (statement  of  work). 

(4)  The  designer  makes  little  or  no  use  of  human  factors  informa¬ 
tion. 

(5)  Human  factors  information  is  considered  by  the  design  engineer 
as  lacking  applicability  to  specific  design  problems. 

C.  PURPOSE  OF  THE  PRESENT  STUDY 

The  present  study  was  conducted  to  determine  the  effect  on  system 
design  of  using  manpower  and  personnel  resources  data  as  design  re¬ 
quirements  and  to  determine  under  what  conditions  these  inputs  can  be 
made  to  have  maximum  influence  on  system  configuration.  One  might 
suppose  after  reading  the  largely  negative  results  of  the  two  previous 
studies  that  no  further  investigation  of  the  effectiveness  of  human  factors 
inputs  need  be  performed.  But,  in  fact,  these  studies  documented  only 
what  is  generally  accepted  by  human  factors  specialists  who  are  in  a 
position  to  observe  the  use  to  which  their  recommendations  are  put. 

Therefore,  as  was  pointed  out  in  sub-section  A  (Nature  of  the  Prob¬ 
lem),  it  is  necessary  to  find  out  why  human  factors  inputs  are  not  effective 
in  system  design  and  under  what  conditions  they  can  be  made  effective. 

The  inputs  provided  to  the  design  engineer  in  the  previous  studies  were 
limited  to  handbook-type  data.  There  are,  moreoever,  a  number  of 
distinctions  between  the  previous  studio  s:(l)  the  inputs  provided  to  the 
design  engineer  in  the  previous  studies  were  limited  to  handbook-type 
data  and  did  not  reflect  manpower  requirements  which  ought,  on  a 
purely  logical  basis,  to  be  considerably  more  relevant  to  the  design  of 
the  system,  (2)  the  inputs  used  as  test  material  in  the  previous  studies 
were  those  which  would  ordinarily  be  supplied  in  the  later  phases  of 
detail  design,  after  fundamental  design  decisions  had  been  made.  Hence, 
one  would  expect  them  to  have  less  influence  on  design  than  PRD  inputs 
which  should  be  applicable  to  the  initial  design  concept;  (3)  the  effective¬ 
ness  of  the  human  engineering  inputs  used  in  the  previous  studies  were 


not  related  to  the  chronological  sequencing  of  system  development,  hence 
it  was  impossible  to  determine  at  what  stage  of  that  development  these 
inputs  could  be  effective. 


Thus,  the  primary  objectives  of  the  present  study,  stated  in  question 
form  were: 

(1)  Do  differences  in  manpower  requirements  (MR)  influence  sub¬ 
system  configuration? 

(2}  Do  personnel  resources  data  (PRD)  inputs  have  a  significant 
effect  on  equipment  design? 

(3)  At  what  stage  of  subsystem  development  do  MR  and  PRD  inputs 
have  their  greatest  impact  on  equipment  design? 

(4)  In  what  forms  are  PRD  inputs  most  effectively  used  by  designers? 

Secondary  questions  necessary  for  a  better  understanding  of  the  design 
process  were: 

(5)  What  is  the  design  engineer's  concept  of  human  factors  in  system 
design,  and  his  attitude  toward  PRD  inputs? 

(6)  How  does  the  manner  in  which  the  engineer  designs  affect  the 
utilisation  of  PRD  inputs? 

(7)  How  available  is  information  as  a  whole  to  the  engineer  during 
design? 
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SECTION  II 
TEST  METHODOLOGY 


A.  GENERAL  STRATEGY 

The  research  strategy  developed  by  Meister  and  Farr  (1966) 
and  Meister  and  Sullivan  (1967)  involves  placing  the  engineer  in  a 
realistic  design  situation  in  which  he  must  solve  a  series  of  design 
problems  by  using  informational  inputs  related  to  these  problems. 

In  adapting  this  general  methodology  to  the  present  study ,  the  fol¬ 
lowing  steps  were  performed: 

(1)  Selection  of  an  already  operational  subsystem  which 
could  serve  as  a  model  subcystem  for  the  development 
of  test  inputs. 

(2)  Selection  of  appropriate  engineer -subjects  skilled  in  de¬ 
sign  of  the  type  of  subsystem  selected. 

(3)  Determination  of  the  equipment  and  PRD  inputs  which 
are  characteristically  provided  during  the  system 
definition  phase  of  development. 

(4)  Development  of  manpower  and  personnel  resources  data 
inputs. 

(5)  Determination  of  the  sequence  in  which  these  inputs  should 
be  provided. 

(6)  Determination  of  the  design  responses  and  outputs  which 
the  engineer -subjects  should  supply  in  attempting  to 
solve  the  design  problems. 

(7)  Determination  of  specific  measures  which  could  be  used 
to  answer  the  questions  which  initiated  the  study.  (See 
Experimental  Design,  page  3?  ). 

B.  DEVELOPMENT  OF  THE  EXPERIMENTAL  SITUATION 
1.  Selection  of  the  Test  Subsystem 

The  initial  step  in  the  development  of  the  experimental  situation 
was  the  selection  of  an  already  operational  subsystem  which  could 
be  used  as  a  model  for  the  development  of  experimental  inputs  and 
required  design  outputs.  Since  one  of  the  goals  of  the  study  was  to 
determine  at  what  stage  PRD  input*  were  most  effective,  and  since 


15 


PRD  inputs  are  supplied  progressively  during  system  development, 
it  was  necessary  to  simulate  the  progressive  development  of  a  sub¬ 
system.  As  the  time  available  for  testing  was  limited,  the  sub¬ 
system  level  was  the  most  complex  which  could  be  handled  reason¬ 
ably  in  the  time  available.  The  subsystem  level  was  also  selected 
as  requiring  a  greater  variety  of  inputs  and  design  outputs  than  the 
development  of  any  single  equipment,  no  matter  how  complex. 

The  original  motivation  for  using  an  already  operational  sub¬ 
system  as  a  model  was  to  permit  the  comparison  of  the  experimental 
subsystem  designs  developed  by  subjects  with  the  original  subsystem 
design.  It  was  hypothesised  that  if  the  experimental  subsystem  was 
developed  with  the  aid  of  PRD  inputs,  the  resultant  design  would  be 
superior  to  the  one  originally  developed.  This,  in  turn,  would 
demonstrate  the  usefulness  of  PRD  inputs. 

Differences  Between  the  Original  and  Test  Subsystem. 

During  the  development  of  the  test  materials,  however,  it  was 
found  that  the  conditions  under  which  the  original  subsystem  was 
designed  were  found  to  be  sufficiently  different  from  those  under 
which  the  experimental  subsystem  was  designed  so  that  any  compar¬ 
ison  of  this  type  would  be  hopelessly  contaminated.  Among  the 
differences  in  design  conditions  between  the  original  and  experimental 
subsystems  were  the  following: 

(1)  The  test  period  during  which  subjects  developed  the 
experimental  subsystem  was  highly  compressed  in  time 
(i.  e.  ,  three  months)  relative  to  the  original  development. 
(Obviously,  since  test  time  was  not  unlimited,  ) 

(2)  The  original  subsystem  design  was  the  product  of  a  large 
number  of  interacting  design  engineers,  some  of  whom 
worked  only  on  minor  phases  of  the  design,  whereas  in 
the  experimental  situation  each  subject  performed  a 
complete  independent  design.  The  reason  for  the  latter 
was  to  secure  a  sufficient  number  ot  independent  designs 
to  test  the  effect  of  the  experimental  variables.  Had  all 
subject?  worked  together  on  the  design  problem,  only  one 
subsystem  would  have  been  available  for  analysis, 

(3)  Although  cost  and  schedule  constraints  were  undoubted 
factors  affecting  the  original  subsystem  design,  these 
parameters  could  not  realistically  be  included  in  the 
experimental  situation.  Schedule  was  irrelevant  to  this 
study,  and  subjects  were  merely  asked  to  minimize  cost 
commensurate  with  safety. 
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(4)  To  maintain  experimental  control,  the  experimental 
situation  had  to  be  orderly  and  progressive,  whereas 
actual  design  is  ordinarily  harassed  by  many  pertur¬ 
bations. 

(5)  The  state  of  the  engineering  art  in  propellant  transfer 
design  had  progressed  between  the  time  the  original 
subsystem  was  designed  and  the  experimental  subsystem 
was  begun;  consequently,  differences  in  selection  of 
components  and  design  concept  would  undoubtedly  be 
found. 

For  all  of  these  reasons,  the  concept  of  comparing  the  original 
subsystem  design  with  the  experimental  subsystem  was  impossible 
to  achieve;  any  such  comparison,  since  it  was  uncontrolled,  would 
have  been  like  comparing  apples  and  oranges.  ^ 

However,  the  ideal  of  using  an  already  operational  subsystem 
as  a  model  was  an  excellent  one,  for  several  reasons: 

(1)  Both  equipment  and  PRD  inputs,  the  details  of  which  would 
otherwise  be  difficult  to  create  if  one  had  to  create  them 
out  of  imagination,  could  be  abstracted  from  the  original 
documentation. 

(2)  The  amount  of  informational  detail  that  should  be  provided 
at  the  various  stages  of  the  experimental  subsystem  de¬ 
velopment  could  be  determined  from  the  original  documen¬ 
tation. 

(3)  The  face  validity  (i.e.  ,  realism)  of  the  inputs  could  be 
assured  because  they  were  produced  in  the  original  sub¬ 
system  design. 

(4)  The  design  responses  required  of  subjects  could  be 
determined  on  the  basis  of  the  design  outputs  developed 
in  the  original  subsystem. 


These  differences,  however,  should  not  lead  the  reader  to  assume 
that  they  invalidated  the  experimental  situation  as  a  tool  for  studying 
the  design  process.  The  essence  of  that  process  - -which  is  the 
presentation  of  realistic  problems  and  realistic  inputs--was  included 
in  the  experimental  simulation.  All  subjects  were  impressed  with 
the  realism  of  the  test  atmosphere,  especially  since  the  testing  was 
conducted  in  their  own  plant  and  practically  at  their  own  desks. 
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Criteria  for  Selecting  the  Operational  Subsystem 


The  criteria  for  selection  of  the  model  subsystem  were  as 
follows: 

(1)  The  subsystem  should  be  one  to  which  personnel  function¬ 
ing  is  important.  Obviously,  the  selection  of  a  subsystem 
which  was  so  automated  as  to  require  few  personnel 
functions  would  not  enable  the  investigators  to  provide 
PRD  inputs  that  could  be  meaningfully  related  to  the 
design  problem. 

(2)  The  subsystem  should  be  one  which  involved  both  opera¬ 
tor  and  maintenance  functions.  This  would  permit  the 
analysis  of  the  effect  of  inputs  related  to  both  types  of 
functions.  If  a  subsystem  was  selected  that  was  com¬ 
pletely  operator  or  completely  maintenance -oriented, 
the  conclusions  derived  would  be  limited. 

(3)  The  subsystem  should  have  an  appropriate  degree  of  com¬ 
plexity.  Overly  simple  subsystems  should  be  avoided 
since  the  number  of  PRD  inputs  and  their  effect  on  sub¬ 
system  design  would  be  minimal.  At  the  same  time  an 
overly  complex  subsystem  would  have  made  it  difficult 

to  supply  the  necessary  subsystem  inputs  within  the  time 
schedule  established.  A  subsystem  requiring  the  services 
of  between  five  and  ten  personnel  was  seen  as  the  ideal 
size. 

(4)  The  subsystem  should  be  one  whose  development  proceeded 
in  accordance  with  AFSCM  375-5  (USAF,  1964)  or  whose 
materials  could  be  so  modified  that  they  fit  into  the  con¬ 
text  of  the  375  system  engineering  approach.  AFSCM 
375-5  is  utilized  as  a  framework  for  the  development  of 
the  experimental  PRD  inputs  because  Air  Force  systems 
are  required  to  be  developed  in  the  spirit,  if  not  to  the 
letter,  of  AFSCM  375-5.  The  historical  records  of  sub¬ 
system  development  should  be  complete  enough  to  mini¬ 
mize  the  development  of  new  material  (as  opposed  to 
editing  or  revision  of  old  material). 

The  Subsystem  Selected 

With  these  criteria  in  mind,  several  alternative  subsystems 
were  considered  and  evaluated  before  the  investigators  selected  the 
model  subsystem. 


The  subsystem  selected  was  the  Propellant  Transfer  and 
Pressurization  Subsystem  (PTPS)  for  the  Titan  III  Space  Launch 
system.  For  those  not  familiar  with  missile  technology,  the  Titan 
III  PTPS  is  a  large  scale  bi-propellant  transfer  subsystem  used  to 
support  a  fixed  base,  two -stage  booster  for  scientific  payloads. 

This  subsystem  is  responsible  for  receiving  propellants  from  rail¬ 
road  cars,  for  storing  propellants  in  Ready  Storage  Vessels  (RSV) 
for  a  period  of  up  to  30  days,  and  for  transferring  the  stored 
propellants  to  the  booster  tanks.  The  propellant  consists  of  a 
mixture  of  nitrogen  tetroxide  as  oxidizer  and  unsymmetrical 
dimethylhydrazine  and  hydrazine,  highly  volatile  and  extremely 
toxic  either  individually  or  in  combination,  automatically  imposing 
the  most  stringent  safety  provisions.  Additional  material  describ¬ 
ing  this  subsystem  can  be  found  in  Appendix  I,  PTPS  statement  of 
work. 

2.  Selection  of  Subjects 

Characteristics.  The  six  engineers  who  made  up  the  subject 
population  for  this  study  were  selected  from  the  Test  Engineering 
Department  of  The  Marquardt  Corporation  (TMC),  Van  Nuys, 
California.  Engineers  were  selected  from  this  company  because 
the  use  of  the  Titan  III  propellant  transfer  subsystem  as  the  model 
for  the  experimental  design  required  the  selection  of  personnel 
skilled  in  the  design  of  propellant  transfer  subsystems. 

The  organizational  structure  within  which  these  subjects 
functioned  made  a  particularly  unique  group  fcr  use  in  a  micro- 
simulation  of  the  design  process.  Each  of  the  subjects  had  been 
and  was  at  the  time  of  testing  charged  with  the  responsibility  for 
the  complete  design  of  propellant  subsystems.  This  included  such 
major  developmental  stages  as  definition  of  initial  system  require¬ 
ments,  development  of  fundamental  design  concepts,  definition  of 
the  equipment  configuration,  costing  the  system  design,  writing  of 
operating  procedures,  and  test  and  operation  of  the  prototype  system. 
Consequently,  they  had  had  extensive  experience  with  all  of  the  phases 
of  system  development  with  which  this  study  was  concerned. 

Sophistication.  In  comparison  with  the  subjects  utilized  in  the 
previous  two  studies  reviewed  in  Section  I,  the  engineer*  in  the 
oresent  study  can  be  considered  the  most  sophisticated.  If  one  de¬ 
fines  a  system  engineer  as  one  who  must  be  concerned  with  all 
aspects  of  the  system  under  development,  they  were  true  system 
engineers.  Moreover,  they  had  a  much  greater  feel  for  the  actual 
molecular  design,  installation  and  operation  of  hardware  than  the 
usual  system  engineer  who  ordinarily  concludes  his  work  at  the 
"paper-work"  stage. 
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During  the  test  sessions,  the  investigators  found  the  engineers 
to  be  an  unusually  qualified  population  with  regard  to  the  type  of 
subsystem  they  were  accustomed  to  design  and  the  problems  Involved 
in  the  operation  of  these  subsystems. 

One  might  ask,  then,  in  advance  of  the  study  results:  Might 
their  very  sophistication  make  these  subjects  non -representative? 

In  actual  subsystem  development  only  highly  qualified  system 
engineers  are  permitted  to  make  fundamental  design  decisions. 

True,  the  investigators  might  have  selected  a  less  experienced 
subject  population;  however,  the  study  results  might  then  have  been 
attacked  as  possibly  resulting  from  subject  unfamiliarity  with  these 
design  problems. 

In  one  respect,  however,  the  engineer -subjects  of  the  present 
study  may  be  considered  atypical,  perhaps.  Because  of  the  extreme 
haaard  involved  in  the  type  of  systems  with  which  they  were  con¬ 
cerned,  they  were  particularly  sensitive  to  the  safety  aspects  of 
the  system.  They,  therefore,  considered  human  factors  in  their 
design  from  the  standpoint  of  avoiding  situations  which  could  be 
hazardous  to  life. 

An  anal,  sis  at  the  education  and  experience  background  of  TMC 
subjects  is  presented  in  Table  I.  The  two  experimental  groups 
described  subsequently  were  equated  on  the  basis  of  number  of  years 
of  experience. 

Once  recovered  from  their  initial  reserve  and  wariness  in  the 
face  of  an  unfamiliar  experience,  all  subjects  were  extremely  co¬ 
operative  and  displayed  great  interest  in  the  pursuit  of  the  study. 

3,  Determination  of  Equipment  Inputs 

In  addition  to  PRD  inputs,  equipment  inputs  were  provided  to  serve 
as  the  context  for  the  PRD  inputs  as  well  as  the  information  base  for  the 
design.  These  included  the  following: 

(1}  Statement  of  work  which  initiated  subsystem  development, 

(2)  System  and  equipment  functional  flow  diagrams  (at  pro¬ 
gressive  levels  of  detail}. 

(3)  Requirements  Allocation  Sheets  (RAS). 

(4)  Descriptions  of  equipment  characteristics. 


(5)  Maintenance  analyse* 


TABLE  I 

SUBJECT  EDUCATION  AND  EXPERIENCE 
Subject  Education  Years  of  Experience 


K 

BSME 

12 

J 

3-1/2  rs.  (M.  E. ) 

15 

D 

BSCE 

15 

S 

2  years  (M.  E.  ) 

U. 

H 

BSME 

26 

N 

BSME 

24 

17.3  Mean 
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To  develop  the  equipment  inputs,  documentation  produced 
during  the  development  of  the  Titan  III  PTPS  was  examined, 
courtesy  of  the  Martin-Denver  and  Ralph  M.  Parsons  Companies, 
and  pertinent  material  extracted.  The  basic  data  sources  reviewed 
are  listed  in  Table  IV,  To  ensure  technical  accuracy  and  complete¬ 
ness  of  the  equipment  inputs  provided  to  the  subjects,  they  were 
reviewed  by  the  Chief  Design  Engineer  of  The  Marquardt  Corporation, 
and  required  revisions  were  incorporated. 

All  inputs  were  provided  in  complete  form  except  where  it  was 
desired  that  the  subject  solve  a  problem  which  required  him  to 
develop  or  complete  some  part  of  the  input.  For  example,  if  system 
functions  on  Requirements  Allocation  Sheets  were  to  be  analyzed  by 
the  subject  to  determine  appropriate  equipment  characteristics,  all 
necessary  data  were  included  on  the  sheets  except  for  those  dealing 
with  the  equipment  characteristics.  Complete  inputs  were  provided 
because  the  designers  were  not  expected  to  be  able  to  develop  all 
the  documentation  which  v^ould  ordinarily  be  developed  due  to  the 
time -scale  involved  in  the  simulation..  Moreover,  all  PR.D  inputs 
were  presented  in  toto,  since  designers  do  not  ordinarily  develop 
such  inputs  and  do  not  have  the  experience  needed  to  do  so.  In 
addition,  it  was  the  designer's  response  to  the  PRD  inputs  as  reflected 
in  his  design  outputs  which  was  of  interest. 

Input  Presentation  Ground  Rules 


The  following  ground  rules  were  followed: 

(1)  Each  PRD  input  was  supplied,  along  with  an  engineering  input 
which  required  some  analysis,  decision  or  drawing.  It  was 
assumed  that  the  engineer  ordinarily  would  not  analyze  PRD 
inputs,  except  in  terms  of  some  system  development  require¬ 
ment  which  involved  the  use  of  that  PRD  input. 

(?.)  All  inputs  to  subjects  were  supplied  in  wiitten  form,  except 
where  immediate  circumstances  (e.  g.  ,  answers  to  questions 
asked  by  the  subject  during  the  test  session)  made  this  impos¬ 
sible.  Any  input  provided  orally  was  documented  immediately 
following  its  transmission. 

f3)  Instructions  to  subjects  were  provided  verbally,  but  they  were 
allowed  to  read  the  same  instructions  in  written  form;  and 
those  written  instructions  were  available  to  him  throughout  the 
test  session. 
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4.  Development  of  the  PRD  Inputg 


Phase  1A/1B 

The  PRD  inputs  selected  for  inclusion  in  the  study  were  those  which 
would  be  developed  as  a  product  of  the  analyses  performed  during  Phase 
1A/1B  in  the  System  Definition  stage  (see  Table  II).  This  stage  ordinar¬ 
ily  follows  the  development  of  the  PTDP  in  the  Conceptual  Transition 
phase  and  the  writing  of  a  Request  for  Proposal  (R1  P)  during  Phase  1A 
for  contractor  definition  of  the  system.  It  precedes  the  Acquisition  stage 
in  which  the  system  is  designed  in  detail.  Ordinarily  contractor  defini¬ 
tion  is  the  second  phase  (IB)  of  System  Definition,  but  occasionally  the 
System  Planning  Phase  (1A)  is  contracted  out,  e.g.  ,  the  411L-AWACS 
presently  under  study.  Hence,  in  referring  to  the  developmental  phase 
which  the  testing  was  designed  to  simulate,  the  term  "phase  1A/1B" 
will  be  used. 

During  the  contractor  definition  phase,  the  planning  analyses  reflected 
in  the  PTDP  and  RFP  are  refined  in  terms  of  an  equipment  configuration 
and  an  appropriate  manning  structure.  The  reason  fcr  cotdining  the  PRD 
inputs  in  this  study  to  phase  1A/1B  is  tnat  the  major  decisions  influencing 
the  system  configuration  are  made  in  this  phase.  If  is  the  effect  of  PRD 
on  these  major  decisions  which  the  study  was  designed  to  investigate. 
Although  it  may  appear  as  if  this  ignores  a  great  deal  of  human  factors 
activity  in  the  Acquisition  stage,  the  detail  design  (including  PRD)  per¬ 
formed  during  Acquisition  represents  only  an  amplification  and  extension 
of  decisions  made  earlier  through  progressive  reiteration  of  earlier 
decisions.  Only  under  conditions  of  a  major  redirection  of  system  re¬ 
quirements  will  decisions  made  during  earlier  phases  (1A  and  IB)  be 
reversed.  Consequently,  the  influence  PRD  can  have  on  system  config¬ 
uration  during  detail  design  is  restricted  to  relatively  molecular  aspects 
of  hardware  configuration. 

Criteria  for  Selection  of  PRD  Inputs 

The  basis  for  selection  of  PRD  inputs  were  the  two  following  ground 
rules: 

(1)  Inputs  must  be  logically  derived  from  and  be  capable  of  being 
tied  to  the  analyses  required  by  the  system  development 
sequence.  It  is  assumed  that  if  PRD  inputs  are  to  be  used  by 
the  design  engineer,  they  must  be  related  to  the  design  prob¬ 
lems  which  arise  during  system  development.  Theoretically, 
there  should  be  a  PRD  input  for  every  engineering  milestone 
and  every  equipment  input;  in  actuality,  no  such  precise  cor¬ 
relations  of  PRD  and  equipment  inputs  can  be  made.  Since 
system  development  activities  are  iterative,  certain  inputs 
may  be  presented  more  than  once  with  increasing  detail  and 
definition. 
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(2)  Within  the  framework  of  system  development  requirements, 
as  described  in  (1),  PRO  inputs  must  also  be  developed  to 
satisfy  certain  personnel  subsystem  requirements  (e.  g.  , 
selection  criteria,  training  courses)  which  demand  certain 
inputs  (e.  g.  ,  skill  and  training  requirements  analyses). 

The  PRD  inputs  provided  are  listed  in  Table  III  and  are  also  presented 
in  Appendix  I. 

5.  Determination  of  the  Sequence  of  Providing  Inputs 

Because  of  the  many  iterations  involved  in  system  development,  the 
developmental  sequence  included  in  this  study  can  only  approximate 
reality.  In  the  development  of  this  sequence,  documentation  describing 
system  development  were  analyzed  and  the  final  sequence  was  checked 
with  a  number  of  experienced  equipment  designers. 

Milestone  Stages 

The  general  milestone  stages  within  phase  1A/1B  were  hypothesized 
to  be  as  follows: 

Once  received,  the  design  Statement  of  Work  (SOW)  is  analyzed  to 
determine  system  functions  and  sub -functions.  Equipment  and  personnel 
functions  based  on  these  are  listed  and  progressively  refined.  Responsi¬ 
bilities  for  performing  system  sub-functions  are  allocated  between  equip¬ 
ment  and  personnel.  Both  equipment  and  personnel  functions  are  organized 
in  terms  of  their  sequential  interrelationships  in  the  form  of  functional 
flow  diagrams.  Based  on  system/mission  requirements  and  the  detailed 
function  flow  diagrams,  a  set  of  equipment  that  will  implement  these 
equipment  functions  are  specified,  and  the  equipment  are  described. 
Hardware  for  controlling  the  equipment  is  specified  (e.  g.  ,  controls  and 
displays)  and  top  level  control  panel  drawings  are  developed.  Mainten¬ 
ance  analyses  are  then  performed.  These  maintenance  analyses  are 
performed  comparatively  late  in  system  development  because  it  is  im¬ 
possible  to  determine  maintenance  requirements  before  sufficiently  de¬ 
tailed  equipment  descriptions  are  available.  Once  control-display 
hardware  has  been  specified,  specific  operating  procedures  can  be 
developed.  Based  on  equipment  descriptions,  a  bill  of  material  (complete 
list  of  hardware  components)  can  be  drawn  up.  The  sequence  is  completed 
when  contract  end-item  (CEI)  specifications  are  drawn  up.  (The  experi¬ 
mental  design  did  not  include  the  development  of  CEI  specifications 
because  these  were  considered  to  be  only  a  summarization  of  the  design 
information  developed  previously). 


TABLE  III 


LIST  AND  DEFINITION  OF  MANPOWER 
REQUIREMENTS  AND  PRD  INPUTS 


L  Manpower  Requirements 
Item 

(1)  QQPRI  data,  including: 

(a)  Number  of  personnel 


(b)  Skill  type 

(c)  Skill  level 

(d)  Proficiency 

(e)  Task  error- 

likelihood 

(f)  Personnel 

availability 

(2)  Training  requirements, 
including: 

(a)  Anticipated  training 

time 

(b)  Required  aptitude 


Definition 


Quantity  of  personnel  required  to 
perform  subsystem  operations, 
defined  initially  in  terms  of  max¬ 
imum  number  to  be  utilized, 
later  in  terms  of  actual  number 
needed. 

Characteristics  of  the  job  to  be 
performed  in  terms  of  demands 
upon  personnel. 

Air  Force  skill  levels  required 
by  the  task,  defined  in  terms  of 
error  probability,  response  time, 
and  amount  of  assistance  required. 

Skill  characteristics  which  person¬ 
nel  should  possess  to  perform  the 
job  satisfactorily. 

Type  of  error  which  may  occur 
during  task  performance. 

Definitions  of  AFSC  type  possessing 
necessary  qualifications  to  perform 
the  job,  together  with  the  probabil¬ 
ity  of  such  personnel  being  available 
for  the  job. 


Time  needed  to  train  to  given  level 
of  proficiency. 

Job  skills  which  training  should 
provide. 
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TABLE  III  (concluded) 


II.  PRD  Inputs 


Item 

(1)  Lists  of  personnel  tasks 

(2)  Personnel/equipment  flow 
diagrams 

(3)  Personnel/equipment 
analyses 

(4)  Task  analysis,  including: 

(a)  Task  structure 

(b)  Task  criticality 

(c)  Team  performance 

(d)  Probability  of 
successful  task 
completion 

(e)  Task  location 

(f)  Task  duration 

(g)  Difficulty  index 

(5)  Time-line  analysis, 
including  task  frequency 


Definition 

Tasks  defined  in  terms  of  personnel 
functions  and  equipment  acted  upon. 

Diagrams  illustrating  the  sequencing 
and  interrelationships  among  tasks. 

Description  of  equipment  character¬ 
istics  required  by  tasks  or  effect  of 
equipment  characteristics  on  task 
performance. 


Task  description  in  terms  of  function 
and  equipment  operated  or  maintained 
(See  Item  (1)). 

Consequences  of  task  being  performed 
incorrectly  or  not  at  all. 

Number  of  personnel  required  to  per¬ 
form  the  task. 

Quantitative  estimate  of  probability 
that  the  task  will  be  completed  success¬ 
fully  by  personnel  (the  converse,  error 
probability,  also  is  provided). 

Approximate  physical  area  (e.  g.  ,  trans¬ 
porter,  launch  pad)  in  which  t.j.e  task 
must  be  performed. 

Estimate  of  the  time  required  to  perform 
a  task. 

Estimated  difficulty  of  task  defined  in 
terms  of  error  probability  and  response 
time. 

Distribution  over  time,  including  over¬ 
laps  of  individual  task  durations. 


-  2? 


TABLE  IV 


BASIC  DATA  SOURCES  FOR  DEVELOPMENT  OF  PTPS  INPUTS 


(1)  Titan  III  Student  Study  Guide,  Propellant  Transfer 
System  ITL  624A-662 

(2)  Task  Analysis  for  PTPS  Launch  and  Checkout 
Equipment  (OSTF) 

(3)  Functional  Flow  Diagrams  for  PTPS 

(4)  Maintenance  Function  Analyses  for  PTPS 

(5)  Design  Specifications  for  Major  End-Items  of  PTPS 

(6)  Operating  Procedures  for  Major  End-Items  of  PTPS 

(7)  Schematics  for  Major  End-Items  of  PTPS 

(8)  Figure  A  Diagrams  for  Major  End-Items  of  PTPS 

(9)  Personnel  Subsystem  Data  Books  WS107A 

Activity  Flow  Diagram 
Launch  Complex  Operations 

(10)  Human  Engineering  Problem  Report 

(11)  Top  Level  Drawings  of  Major  End-Items  of  PTPS 

(12)  Panel  Installation  Drawings 

(13)  Acceptance  Criteria  for  Major  End-Items  of  PTPS 

(14)  Bill  of  Material  for  tylajor  End-Items  of  PTPS  (fuel) 


Revised  5/26/66 

August  1959 

Revised  3/10/67 
Revised  7/17/67 
Revised  3/16/65 
Revised  11/17/66 
Revised  11/17/66 
August  8,  1963 

January  1961 
November  1962 

February  21,  1964 

Revised  1/25/67 

Revised  4/5/67 

Revised  5/8/64 

Revised  1/20/67 


$ 

The  following  classes  of  informational  inputs  were  used  to  develop  the 
PTPS  inputs.  The  number  of  items  within  each  class  is  so  long  that  a 
complete  bibliography  is  not  included. 
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TABLE  IV  (c one luded) 


(15)  Component  Lists  for  Major  End-Items  of  PTPS 

(fuel) 

(16)  System  Installation  Diagrams  for  PTPS 

(17)  Equipment  Specifications  for  Major  End-Items 

of  PTPS 

(18)  Decal  Drawings 

(19)  Basic  QQPRI  for  Titan  II 

(20)  Forms  C  and  C 1  (Maintenance  Analysis)  for 

PTPS  for  Titan  II 


Revised  1/5/67 

Revised  5/31/67 
Revised  7/11/67 

Revised  8/31/66 
January  19b2 
January  1962 
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Sequence  of  PRD  Inputs 


It  is  somewhat  more  difficult  to  specify  the  PRD  inputs  which  should 
be  provided  at  each  milestone  stage.  Although  AFSCM  375-5  (USAF, 

1964)  prescribes  a  seq-’-nce/milestone  schedule  for  PRD  inputs,  this 
schedule  is  somewhat  gross  and  replete  with  iterations.  Tentatively 
the  following  sequence  was  hypothesized,  based  partially  on  375-5  and 
partially  on  interviews  with  a  number  of  experienced  design  engineers. 

Personnel  functions  and  function  flow  diagrams  should  be  provided 
at  the  same  time  engineers  are  analyzing  equipment  functions.  Personnel 
tasks  and  performance  requirements  should  accompany  the  listing  of  re¬ 
quired  equipment  and  equipment  descriptions.  Personnel/equipment 
analyses  should  be  provided  as  soon  as  initial  equipment  descriptions  are 
available.  Task  analyses  should  be  available  at  the  time  the  engineer  is 
deciding  on  control  equipment.  A  description  of  personnel  tasks  involved 
in  maintenance  should  be  available  when  the  designer  is  performing  his 
maintenance  analysis.  Preliminary  QQPRI  should  be  available  by  the 
time  operating  procedures  are  being  developed.  Final  QQPRI  should  be 
available  prior  to  the  development  of  the  CEI  specification. 

Throughout  the  process,  there  are  repetitive  iterations  of  sub-stages 
designed  to  refine  individual  design  outputs.  The  entire  process  is 
schematically  represented  in  Figure  1.  The  test  sequence  as  finally  ad¬ 
ministered  to  subjects  is  shown  in  Table  V  and  may  also  be  reviewed  in 
Appendix  I. 

One  may  ask  whether  the  developmental  sequence  shown  in  Table  V 
represents  the  "real  world"  sequence  in  which  inputs  are  made  and  de¬ 
sign  activities  are  performed.  The  development  of  the  design  sequence 
in  the  study  was  admittedly  one  of  the  most  difficult  tasks  the  investiga¬ 
tors  had,  because  of  the  complexity  of  the  activities  involved.  Subjects 
questioned  concerning  the  realism  of  the  inputs  and  the  sequence  of 
simulated  events  indicated  that  these  were  generally  characteristic  of 
the  order  in  which  they  received  their  inputs.  However,  as  shall  be 
seen  later,  certain  modifications  in  this  concept  of  how  system  design 
proceeds  during  system  definition  were  made  necessary  by  the  perform¬ 
ance  of  the  subjects. 

Test  Procedure 


The  general  procedure  for  the  individual  sessions  was  to  determine 
the  effect  of  a  particular  input  on  the  design  task.  At  the  start  of  any 
session,  the  engineer  was  told  his  design  task,  the  inputs  available  to 
him  were  described,  and  he  was  asked  to  review  them  (in  the  event  he 
had  not  reviewed  them  since  he  was  first  handed  them  at  the  close  of 
the  previous  session).  The  subject  then  performed  his  design  task. 


-  30  - 


XA/1B 


TABLE  V 


s equence  OF  INPUTS  AND  OUTPUTS 
FOR  DESIGN  OF  EXPERIMENTAL  SUBSYSTEM 


1,  Introduction 

Group  session.  Subject  is  informed  of  the  nature  of  the  study. 


2.  Session  1 


(a)  Equipment  input.  Statement  of  work  (SOW)  which  contains 
lop  level  function  flow  diagrams. 

(b)  Personnel  input.  Flow  diagrams  of  personnel  operations,  and 
SOW  containing'qualitative  and  quantitative  personnel  require¬ 
ments. 


(c)  Required  output.  Subject  will  develop  two  flow  diagrams  of 
detailed  subfunctions,  one  for  transfer  of  fuel  from  trans¬ 
porter  to  RSV;  the  other,  for  fuel  transfer  between  RSV  and 
rocket  tank*.  Subject  will  indicate  on  the  flow  di-n:ams  which 
functions  are  to  be  performed  by  personnel  and  which  are  to 
be  performed  by  equipment. 

The  control  group*  will  receive  no  personnel  input;  this  pro¬ 
cedure  will  be  followed  wherever  a  control  group  is  noted  in 
Che  following  subsections. 


3 .  Session  2 . 

(a)  .Equipment  input.  Partially  filled  out  Requirements  Allocation 
Sheets  (RXSj  (T7e.  ,  statement  of  design  requirements). 

(b)  Personnel  input.  Personnel  section  of  RAS  filled  out  in  addition 
io  »  more  detailed  personnel  flow  diagram  which  essentially 
replicates  the  RAS  material  in  graphic  form. 

(c)  Required  output.  Subject  will  describe  »he  equipment  required 
emenl  resign  requirements.  Control  group. 


io  Imp! 


4.  Section  3. 

(a)  Equipment  input.  Supplementary  sheets  to  RAS  containing 
additional  equipment  detail. 


During  each  session,  four  of  the  designers  were  experimental  subjects 
and  two  were  control  subjects  (see  page  45) 
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TABLE  V  (continued) 


(b)  Personnel  input.  Memorandum  analyzing  control-display 
requirements. 

(c)  Required  output.  Subject  will  review  and  amplify  equipment 
descriptions;  also,  subject  will  develop  equipment  flow 
diagram.  Control  group. 

5.  Session  4 

(a)  Equipment  input.  Additional  supplementary  sheets  to  RAS. 

(b)  Personnel  input.  Preliminary  task  analysis  of  operations. 

(c)  Required  output.  Subject  will  develop  list  of  control-display 
hardware  required  to  opera.te  the  system.  He  also  will 
indicate  how  many  men  of  what  types  would  be  required  to  man 
the  system.  Control  group. 

6.  Session  5 

(a)  Equipment  input.  New  RAS  sheets  covering  preventive  main- 
tenance.  A  maintainability  design  checklist  will  be  furnished. 

(b)  Personnel  input.  Personnel  section  of  RAS  will  include 
description  of  functional  steps  required  to  perform  preventive 
maintenance.  A  maintainability  design  checklist  will  be 
furnished. 

(c)  Required  output.  Subject  will  provide  flow  diagram  of  detailed 
preventive  maintenance  subfunctions.  He  also  will  list  any 
special  maintenance/test  equipment  which  would  be  required, 
indicating  all  special  design  features  which  would  assist  per¬ 
sonnel  performance  of  preventive  maintenance.  He  also  will 
indicate  the  number  of  maintenance  men.  Control  group. 

7.  Session  6a 


(a)  Equipment  input.  None. 

(b)  Personnel  input.  Two  time-line  analyses  (one  for  operation, 
one  for  preventive  maintenance)  per  function  to  be  performed. 

(c)  Required  output.  Subject  will  indicate  how  many  control -display 
panels  are  required  for  his  design  and  where  they  should  be 
located.  He  will  supply  a  rough  sketch  of  the  panels,  indicating 
the  functions  to  be  covered  and  the  approximate  arrangement 

of  the  control-display  devices.  Control  group. 
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TABLE  V  (continued) 


8.  Session  6b 

(a)  Equipment  input.  None 

(b)  Personnel  input.  Preliminary  QQPRI,  including  numbers  of 
personnel  anti  position  description. 

(c)  P  equired  output.  Subject  will  continue  his  panel  layouts  if  he 
has  not  completed  them.  In  addition,  he  will  list  the  steps 
required  to  operate  the  control -display  equipment.  The  con¬ 
trol  group  specified  for  Session  6a  also  will  be  used  for  this 
session. 

9.  Ses s ion  7a 

(a)  Equipment  input.  None. 

(b)  Personnel  input.  Full  stale  QQPRI,  including  numbers  of 
personnel,  skill  level,  anticipated  reliability,  training 
requirements,  etc.  The  QQPRI  also  will  include  a  list  of 
potential  human  errors. 

(c)  Required  output.  Subject  will  list  all  potential  operating 
problem 8  and  indicate  design  solutions  for  these.  Control 
group. 

10.  Session  7b 

This  will  be  a  continuation  of  Session  7a,  Subject  will  review  the 
design  in  the  light  of  the  QQPRI  and  will  develop  a  complete  list 
of  equipment  required.  This  li3t  will  be  used  by  the  cost  estima¬ 
tors  and  reliability  specialists  in  the  final  evaluation  of  subsystem 
design.  Same  control  group  as  in  Session  7a. 

11.  Session 


(a)  Personnel/equipiT-'mt  input.  Memorandum  from  SPO  reverting 
personnel  requirements  and  directing  redesign  of  the  FTPS. 

(b)  Required  output.  Subject  will  review  his  past  design  and 
recommend  design  modifications  to  meet  new  personnel  re¬ 
quirements,  No  control  group. 
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TABLE  V  (concluded) 


12.  Session  9 

Presentation  of  special  problems.  No  control  group. 

13.  Session  10 

Presentation  of  special  problems.  No  control  group. 
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About  a  half  hour  before  the  end  of  the  session  (unless  he  obviously 
was  not  finished,  in  which  case  the  session  would  be  continued  to  the 
following  week),  the  subject  was  informed  that  his  work  was  to  be  re¬ 
viewed.  His  output  then  was  reviewed  by  thr  investigator  with  him  to 
elicit  any  additional  information  and  particularly  the  reasons  why  par¬ 
ticular  design  features  were  incorporated.  At  the  same  time,  the  sub¬ 
ject  was  questioned  to  determine  whether:  (1)  he  thought  the  input  was 
useful,  (2)  the  input  was  understandable  and  meaningful,  (3)  he  used 
the  input  in  deriving  his  design  product,  (4)  the  format  of  the  input  was 
satisfactory,  (5)  the  timing  of  the  input  was  appropriate,  and  (6)  any 
additional  information  was  needed. 

At  the  close  of  the  session  he  was  handed  the  inputs  for  the  next 
session  and  asked  to  study  them  if  he  had  sufficient  time. 

The  progressive  development  of  the  experimental  subsystem  was 
simulated  by  scheduling  each  subject  individually  for  a  minimum  of  10 
weekly  three-to  four-hour  sessions  (the  length  of  the  session  depending 
on  their  speed.  A  few  subjects  spent  hours  between  sessions  elaborat¬ 
ing  their  design  outputs,  a  tribute  to  their  interest  in  the  project).  In 
each  session,  the  subject  received  increments  of  data  corresponding  to 
those  which  he  would  ordinarily  have  received  as  system  design  pro¬ 
gressed  and  became  more  complex.  For  example,  in  the  first  session 
he  would  have  available  to  him  only  the  design  statement  of  work,  plus 
a  list  of  personnel  functions;  by  the  fourth  session  he  would  have  a  vastly 
increased  amount  of  equipment  information  plus  a  preliminary  task 
analysis  of  operations;  by  the  sixth  session  a  time-line  analysis,  etc. 
Naturally,  he  would  have  available  to  him  at  each  successive  test 
session  all  the  data  (and  his  previous  design  outputs)  from  preceding 
sessions.  At  each  session,  the  subject  would  be  asked  to  supply  cer¬ 
tain  design  outputs  which  the  investigators  hypothesized  should  be 
affected  by  the  PRD  input  for  that  session. 

6.  Determination  of  Design  Outputs 

The  response  secured  from  the  subjects  fell  into  two  general  classes, 
attitudinal  or  subjective  outputs,  and  application,  or  product  outputs. 

When  a  PRD  input  was  first  presented  to  a  subject  he  was  asked 
(after  he  had  reviewed  the  input)  to  indicate  his  personal  response  to 
the  input.  By  this  is  meant  that  the  investigators  sought  to  determine 
how  the  subject  felt  about  his  immediate  input;  whether  he  understood 
it,  and  if  not,  why;  whether  he  felt  he  could  use  the  input,  and  if  not, 
why;  etc.  Since  the  engineer  must  first  be  positively  motivated  to 
accept  an  input  before  he  applies  it,  subjective  responses  were  secured 
before  proceeding  to  more  objective  outputs. 
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After  the  subject  completed  his  subjective  evaluation  of  the  input, 
he  was  required  to  make  use  of  the  input  by  performing  some  engineer¬ 
ing  analysis  or  developing  some  engineering  output,  such  as  a  drawing 
to  which  the  PRD  input  was  related.  He  was  required  to  make  use  of 
the  PRD  input  even  though  he  may  have  indicated  earlier  that  he  could 
make  little  use  of  it.  This  was  because  his  subjective  response  might 
or  might  not  have  been  related  to  his  objective  output.  (To  anticipate 
the  data,  certain  inputs  overtly  rejected  by  the  engineer  were  still  of 
value  to  his  design  in  terms  of,  for  example,  reminding  him  of  certain 
parameters  he  had  overlooked.  ) 

Subjective  Outputs 

The  kinds  of  subjective  outputs  to  be  sought  of  the  subject  were  as 
follows: 

(1)  Preference  responses,  e.g.  ,  I  will  accept/not  accept  the  input. 

(2)  Utility  responses,  e.  g.  ,  I  can/cannot  apply  the  input  to  system 
design. 

(3)  Knowledge  responses,  e.g.  ,  I  understand/do  not  understand 
the  input. 

(4)  Implication  responses,  e.g.  ,  I  draw  the  following  implications 
from  the  input;  the  following  consequences  result  from  the 
input. 

(5)  Schedule  responses,  e.g.  ,  the  input  is  too  early/ too  late/  just 
in  time. 

(6)  Impact  (effect)  responses,  e.g.  ,  my  design  is/  is  not  influenced 
by  the  input. 

(7)  Format  responses,  e.  g.  ,  I  would  prefer  the  input  to  be  in  the 
following  format. 

Although  there  was  some  slight  overlap  among  these  responses 
(e.  g.  ,  utility  would  seem  to  imply  preference),  each  of  these  response 
types  was  considered  separately  because  they  could  be  combined  in 
different  ways,  such  as  understanding  an  input  but  rejecting  it  as  being 
inappropriately  timed. 

Product  Outputs 

The  subject's  product  outputs  could  fall  into  two  general  classes: 
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(1)  Analytic/decision  responses,  e.  g.  ,  determination  of  functions, 
specification  of  system/equipment  characteristics  and  operat¬ 
ing  modes. 

(2)  Drawing  responses,  e.g.,  physical  layout  of  equipment.  These 
might  be  affected  in  any  number  of  ways.  For  example: 

(a)  The  number  of  components  in  a  drawing  could  be  increased 
or  decreased; 

(b)  The  type  of  component,  its  function  or  the  manner  in  which 
it  operated  could  be  changed; 

(c)  Tasks  might  be  added  or  deleted  or  their  nature  changed; 

(d)  The  number  and  type  of  personnel  required  might  be 
modified,  etc. 

The  specific  design  responses  required  of  subjects  are  listed  in 
Table  V  under  the  heading  "Required  Output.  " 

The  engineer's  subjective  responses  (e.g.,  attitudes,  preferences) 
may  more  directly  indicate  the  utility  of  the  PRD  input  than  do  his  de¬ 
sign  outputs.  The  engineer  had  an  opinion  specifically  about  an  input 
(e.g. ,  yes,  it  is  useful;  no,  it  is  not);  his  design  output,  such  as  a 
drawing,  was  influenced  by  a  number  of  factors,  only  one  of  which  might 
be  the  PRD  input.  Consequently,  it  might  be  more  difficult  to  differ¬ 
entiate  the  effect  of  that  input  on  the  drawing  from  the  other  influential 
factors  (e.g.  ,  cost,  reliability  and  safety  considerations). 

Note  that  to  extract  the  necessary  data  from  subjects ,  the  equivalent 
of  an  in-depth  interview  (debriefing)  was  conducted  with  subjects  to  ex¬ 
plore  the  rationale  for  their  responses. 

7.  Determination  of  Specific  Measures 

The  measures  of  the  effectiveness  of  MR  and  PRD  inputs  on  sub¬ 
system  design  were  derived  from  the  specific  objectives  of  the  study 
(see  page  14  ).  To  understand  the  rationale  for  these  measures,  it  is 
necessary  to  consider  them  in  terms  of  the  overall  experimental  design 
of  the  study.  This  study  design  and  its  related  effectiveness  measures 
are  discussed  in  detail  in  the  following  section. 
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EXPERIMENTAL  DESIGN 


Introduction 

To  explain  the  reason  why  the  experimental  design  for  this 
study  was  created  the  way  it  was  and  the  reasons  for  the  various 
analyses  which  were  performed,  this  sub-section  has  been 
organized  in  terms  of  the  specific  questions  which  the  study  was 
designed  to  answer. 

1.  Do  Differences  in  Manpower  Requirements  Influence  Sub- 

system  Design?' 

Quantitative  Analyses 

The  six  subjects  were  divided  into  two  groups  which  received 
different  personnel  requirements  in  their  design  statement  of  work 
(SOW),  Subjects  in  one  group  of  three  received  as  part  of  their 
SOW  the  requirement  that  they  minimize  the  skill  demanded  of  the 
operating  personnel.  This  group  was  termed  the  Low  Skill/High 
Number  (of  personnel)  group,  henceforth  to  be  referred  to  as  the 
LS/H#  group,  because  in  any  design  tradeoff  the  engineer -subjects 
could  compensate  for  minimizing  skill  level  by  increasing  the 
number  of  personnel  they  required. 

Subjects  in  the  second  group  of  three  (High  Skill/Low  Number 
(of  personnel)  or  HS/L#  group)  received  as  part  of  their  SOW 
(otherwise  identical  with  that  of  the  other  group)  the  information 
that  highly  skilled  personnel  would  become  available  as  operators 
for  their  subsystem,  and  that  consequently  n  any  design  tradeoffs 
they  should  minimize  the  number  of  personnel  they  required. 

Presumably  if  the  differing  personnel  requirements  influenced 
the  engineers'  design,  it  would  be  reflected  in  the  characteristics 
of  the  design  outputs  they  produced  (e.  g.  ,  function  flow  diagrams, 
number  and  type  of  equipment  components,  operating  problems 
anticipated,  etc.  ). 

Two  general  types  of  measures  could  be  utilized  in  comparing 
the  two  experimental  groups.  Since  each  session  required  a 
specific  design  output,  it  would  be  possible  to  compare  the  perform¬ 
ance  of  the  two  groups  on  a  session-by-session  basis.  A  list  of  the 
session-by-session  analyses  performed  Is  presented  in  Table  VI, 

Alternately,  one  could  expect  that  the  overall  subsystem  design 
would  be  influenced  by  personnel  requirement's!  That  overall  design 
would  consist  of  the  following  design  outputs  produced  during  the 
testing  and  accumulated  at  the  conclusion  of  the  study: 


TABLE  VI 


QUANTITATIVE  MEASURES  OF  THE  EFFECT 
OF  PERSONNEL  REQUIREMENTS  AND  PRD  INPUTS 


1.  Session  1 

Comparison  of  flow  diagrams  produced  by  the  experimental  and  con¬ 
trol  subjects  is  as  follows: 

(1)  The  mean  number  of  personnel -related  functions  produced  by 
the  experimental  groups  contrasted  with  the  mean  number  of 
personnel-related  functions  for  the  control  group. 

2.  Sessions  2-3 


Comparison  of  experimental  and  control  subjects  in  terms  of  the  total 
number  of  personnel -related  equipment  items  listed  by  subjects  in 
completing  their  RAS. 

3.  Session  4 

Comparison  of  experimental  and  control  subjects  in  terms  of: 

(1)  Total  number  of  control -display  hardware  items  noted. 

(2)  Comparison  of  manpower  estimates. 

4.  Session  5 

As  in  Session  1,  comparison  of  experimental  and  control  subjects  in 
terms  of: 

(1)  Number  of  maintenance /test  equipment  items  listed. 

(2)  Manpower  estimates. 

5.  Sessions  6a  and  6b 


Using  the  combined  outputs  of  Sessions  6a  and  6b  (control  panel  lay¬ 
outs  and  operating  procedures),  a  quantitative  estimate  of  personnel 
performance  (in  probability  terms)  was  made. 

6,  Session  7a 

Comparison  of  experimental  and  control  subjects  in  terms  of  number 
of  operating  problems  described. 
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TABLE  VI  (concluded) 


7.  Session  7b 

The  equipment  list  supplied  in  this  session  was  evaluated,  together 
with  the  equipment  descriptions,  by  specialists  in  pricing,  reliability, 
safety  and  design  specialists  to  secure  rankings  of  the  subsystem 
designs.  The  six  designs  were  ranked  in  terms  of  the  four  sets  of 
criteria  individually  and  then  a  mean  rank  for  each  design  was  estab¬ 
lished.  The  rankings  also  were  intercorrelated. 

8.  Session  8 

Comparison  made  of  the  number  and  type  of  design  changes  recom¬ 
mended  to  satisfy  changed  personnel  requirements. 

9.  Sessions  9-10 

(1)  Consistency  of  rankings  given  to  design  parameters,  subsystem 
inputs,  informational  and  manpower  requirements. 

(2)  Mean  rank  order  given  to  various  developmental  and  informa¬ 
tional  inputs,  e.  g.  ,  equipment  requirements,  number  of 
personnel  available  and  task  descriptions. 
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(1)  control  panel  drawings ,  schematics,  function  flow 
diagrams; 

(2)  equipment  descriptions,  tolerances  and  bill  of 
materials; 

(3)  operating  procedures. 

If  one  took  these  three  products  as  a  v/hole,  it  would  be  possible 
to  compare  the  performance  of  the  two  groups  in  terms  of  the 
adequacy  of  their  overall  subsystem  designs.  This  type  of  compari¬ 
son  utilizes  what  are  generally  termed  as  "system  effectiveness" 
measures.  They  can  be  applied  only  to  an  evaluation  of  completed 
subsystem  designs,  not  to  output  responses  to  the  individual  inputs. 
The  reason  for  not  applying  them  to  individual  output  responses  is 
because  these  measures  are  uniquely  fitted  for  evaluation  of  total 
system  complexes,  rather  than  parts  of  systems. 

Five  types  of  subsystem  design  analyses  were  possible: 

(1)  Cost,  Cost  is  taken  to  mean  the  cost  required  to  fabricate 
and/or  procure  the  first  production  model  of  the  system, 
including  required  maintenance  equipment.  Because  of 
study  limitations  of  time,  and  money,  it  does  not  include 
research  and  development,  testing,  operating  or  support 
costs  which  would  be  included  in  a  thorough  analysis  of 
life  cycle  costs. 

(2)  Design  adequacy.  Design  adequacy  is  defined  as  the  sub¬ 
system's  potential  for  efficient  performance  based  on  its 
physical  configuration.  Although  this  evaluation  must  by 
its  nature  be  subjective,  it  is  measured  by  criteria  such 
as  satisfaction  of  all  required  sut  system  functions,  sim¬ 
plicity  of  operation  and  redundancy  of  elements  where 
required. 

(3)  Safety.  Safety  involves  two  factors:  personnel  hazard 
and  protection  of  the  equipment  from  catastrophic  failure. 
The  specific  assumptions  utilized  in  the  safety  evaluation 
are  listed  in  Appendix  II. 

(4)  Reliability  ot  performance:  equipment.  Reliability  is  the 
probability  of  a  device  performing  its  purpose  adequately 
for  a  period  of  time  intended  under  the  operating  conditions 
er.counte red.  Simply  stated,  it  represents  the  probability 
of  successful  operation.  In  the  context  of  the  present 
study,  a  reliability  measure  of  the  subsystem  design 


-  42 


indicates  quantitatively  how  well  designed  the  subsystem  is 
for  performance.  (Obviously,  the  design  adequacy  and 
equipment  reliability  measures  are  related,  the  former 
representing  a  more  subjective  evaluation  of  performance 
probability  but  probably  containing  some  elements  not  con¬ 
tained  in  the  latter. )  It  is  hypothesized  that  a  more  effective¬ 
ly  designed  subsystem- -one  of  the  hallmarks  of  which  would  be 
the  consideration  of  personnel  factors  in  the  design  -  -should 
have  a  higher  reliability.  A  detailed  description  of  the  pro¬ 
cedures  by  which  subsystem  design  reliability  is  estimated 
would  be  of  interest  largely  to  the  equipment  reliability 
engineer;  hence  it  is  included  in  Appendix  II. 

(5)  Reliability  of  performance:  personnel.  To  the  extent  that 
personnel  requirements  and  PRD  inputs  are  ..icorporated  ir. 
subsystem  design,  one  would  expect  that  the  anticipated  re¬ 
liability  of  subsystem  personnel  performance  would  be  con¬ 
siderably  increased.  The  personnel  component  of  overall 
subsystem  reliability  (commonly  termed  "human  reliability") 
should  be  most  directly,  immediately  related  to  personnel 
inputs,  whereas  equipment  reliability  would  be  only  indirectly 
affected  by  such  inputs. 

Hence  it  was  decided  to  make  a  human  reliability  estimate  of 
the  completed  subsystem  designs  and  to  compare  this  estimate 
with  the  equipment  reliability  estimate  of  the  same  design. 

Because  the  technique  for  developing  human  reliability  esti¬ 
mates  is  quite  new,  there  is  some  point  to  describing  it  in 
detail. 

Human  reliability  in_ices  predict  the  effectiveness  with  which 
personnel  will  utilize  the  system  in  the  operational  environ¬ 
ment.  The  technique,  which  is  au  application  of  reliability 
engineering  procedures  to  human  performance  problems,  is 
discussed  in  brief  in  Hornyak  (196?). 

Briefly,  the  technique  involves  four  major  steps: 

(1)  Analysis  of  the  system  or  subsystem  into  discrete  measure- 
able  units.  The  technique  takes  advantage  of  the  usual  task 
analysis  or- -in  the  case  of  the  present  study,  the  operating 
procedures  and  control  panel  diagrams  developed  by  eacn 
subject--to  derive  these  units,  each  of  which  contains  inform¬ 
ation  concerning  the  operator's  behavior  in  terms  of  initiat¬ 
ing  stimuli,  mediating  processes,  and  motor  responses. 
Consequently,  the  major  work  involved  in  applying  the  tech¬ 
nique  is  already  performed  as  part  of  the  usual  subsystem 
analysis. 
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(2)  Analysis  of  the  subsystem  operations  in  terms  of  certain 
parameters  of  correct  performance  of  the  unit.  The  list  of 
13  parameters  includes  such  aspects  as  the  presence  or  ab¬ 
sence  of  feedback,  the  degree  of  stress  imposed  on  the 
operator,  type  and  number  of  stimuli  presented,  etc. 

(3)  Assignment  of  predictive  values  (probability  of  successful 
task/unit  performance)  to  the  behavioral  units.  This  is  done 
on  the  basis  of  tables  of  expected  probabilities  derived  from 
data  found  in  the  experimental  literature.  (Tables  of  predic¬ 
tive  values  are  included  in  Horcyak  (1967)).  For  each 
parameter  found  influencing  the  behavioral  unit,  an  expected 
decrement  of  performance  is  ascertained  from  the  tables, 

and  that  decrement  is  subtracted  from  1.  0  (so-called  "optimal"1 
performance)  to  secure  a  probability  of  successful  task 
performance. 

(4)  Combination  of  unit  probabilities  into  a  total,  unitary  figure  of 
merit  reflecting  the  overall  expected  probability  of  successful 
utilization  of  the  subsystem.  The  individual  unit  probabilities 
are  combined  mathematically  on  the  basis  of  the  independence/ 
dependence  relationships  among  the  units. 

The  whole  approach  parallels  the  development  of  reliability  indices 
describing  the  expected  probability  of  equipment  functioning.  Although 
the  technique  is  still  embryonic  and  depends  a  great  deal  on  the  avail¬ 
ability  of  performance  data  from  the  experimental  literature,  it  appears 
perfectly  suited  for  application  to  the  problem  of  comparing  design 
configurations. 

Qualitative  Analyses 

During  the  simulated  development  cycle  (at  session  8),  the  personnel 
requirements  given  the  two  groups  of  subjects  were  modified  by  exchang¬ 
ing  these  requirements  between  the  two  groups.  In  other  words,  the  LS/H# 
group  had  the  number  of  personnel  available  to  thorn  cut  in  half  (the  precise 
number  depending  on  the  subject's  own  manpower  estimate  developed  in 
sessiou  4),  but  the  skill  level  of  the  remaining  crew  members  was  corres¬ 
pondingly  raised.  The  HS/L#  group  had  the  number  of  personnel  available 
to  them  raised  (depending  on  their  original  manpower  estimates)  but  the 
skill  level  has  correspondingly  reduced. 

The  subjects  were  then  required  to  analyze  their  previous  design  con¬ 
figurations  in  terms  of  the  new  personnel  requirements.  Presumably, 
if  the  reversed  requirements  had  any  effect,  they  should  result  in  revised 

designs. 
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Information  concerning  the  influence  of  personnel  requirements  was 
also  secured  by  interviewing  the  engineer -subject,  particularly  at  the 
conclusion  of  the  first  session  and  during  sessions  9  and  10.  Since  the 
initial  personnel  requirements  were  contained  in  the  SOW  which  was  the 
primary  input  for  session  1,  subjects  could  be  asked  the  following  ques¬ 
tions:  How  do  you  think  the  personnel  requirements  in  the  SOW  will 
affect  your  design?  Do  you  think  they  will  have  any  significant  effect  on 
your  design?  In  what  way?  Similar  questions  were  asked  at  the  conclu¬ 
sion  of  session  8. 

Several  of  the  questions  in  sessions  9  and  10  (see  Appendix  I)  dealt 
with  the  influence  of  varying  numbers  and  types  of  personnel  on  equipment 
design.  For  example,  in  one  question,  subjects  were  asked  how  they  would 
design  a  propellant  transfer  system  if  only  two  personnel  were  available; 
or  to  contrast  the  effect  on  their  design  of  Marquardt  technicians  vs.  Air 
Force  personnel. 

2.  Do  Personnel  Resources  Data  Inputs  Have  a  Significant  Effect  on 

Equipment  Design?  ~~ 

Quantitative  Analyses 

The  most  effective  way  of  demonstrating  that  a  personnel  resources 
data  input  has  an  effect  on  design  is  to  contrast  the  performance  of  sub¬ 
jects  who  have  been  exposed  to  that  input  (i.  e.  ,  experimental  subjects) 
with  the  performance  of  other  subjects  who  have  not  received  that  input 
(i.  e.  ,  control  subjects).  Although  it  is  somewhat  unrealistic  to  assume 
the  absence  of  any  PRD  inputs  at  all  in  the  development  of  a  system 
created  to  military  specifications,  it  seemed  worthwhile  to  maximize  the 
opportunity  of  demonstrating  that  under  optimal  conditions  the  PRD  input 
will  have  a  significant  effect  on  design. 

Consequently,  in  addition  to  the  two  experimental  groups,  it  appeared 
worthwhile  to  add  a  control  group  which  did  not  receive  the  PRD  input.  It 
was  undesirable,  however,  to  segregate  two  or  three  of  the  six  subjects 
as  a  permanent  control  group.  This  would  create  the  artificial  situation 
referred  to  previously  of  a  group  of  design  engineers  who  never  experi¬ 
enced  PRD  inputs  through  the  simulated  developmental  sequence.  More¬ 
over,  it  would  drastically  reduce  the  number  of  subjects  exposed  to  each 
experimental  variable. 

Consequently,  it  was  decided  to  create  a  control  group  by  systemat¬ 
ically  selecting  two  different  subjects  in  each  test  session  who  would  not 
receive  the  PRD  input  for  that  session. 

Thus,  in  session  1,  subject  3  in  both  groups  acted  as  a  control  by  rot 
receiving  the  PRD  input;  all  others  received  their  appropriate  inputs. 

Note  that  all  subjects,  both  experimental  and  control,  always  received 
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their  equipment  inputs  in  every  session;  t he  control  subjects  differed 
frrm  the  experimental  subjects  only  in  not  receiving  the  PRD  input. 


In  session  2,  subject  2  in  both  groups  acted  as  a  control,  while  all 
other  subjects  (including  those  who  in  the  previous  session  had  acted  as 
controls)  received  both  equipment  and  PRD  inputs.  The  control  subjects 
who  in  session  2  became  experimental  subjects  now  received  the  PRD 
input  they  missed  in  the  previous  test  session  (1);  however,  it  did  them 
no  good  for  that  previous  session's  work.  They  were  given  the  PRD  in¬ 
put,  however,  so  that  they  could  catch  up  with  the  other  subjects  in  their 
group. 

This  process  was  continued  throughout  the  test  sessions  as  shown  in 
Tabic  VII,  with  the  excef  :on  of  sessions  8,  9  and  10,  which  were  pre¬ 
sented  to  all  subjects  in  the  same  manner. 

The  major  advantage  with  this  procedure  of  selecting  control  subjects 
was  that,  first,  it  avoided  the  artificiality  of  eliminating  all  PRD  inputs 
for  the  control  group;  second,  it  permitted  us  to  examine  what  the  subject's 
reaction  to  the  PRD  input  was  when  it  arrived  late.  Obviously,  when  a  sub¬ 
ject  who  was  a  control  in  session  2  received  the  PRD  input  for  session  2 
in  session  3,  that  input  was,  as  far  as  ’._e  was  concerned,  late  for  the  de¬ 
sign  work  he  performed  in  the  previous  session.  Finally,  while  only  two 
subjects  formed  the  control  group,  their  variability  was  representative  of 
the  entire  subject  population,  which  made  them  much  more  representative 
of  the  engineering  population  as  a  whole. 

The  one  disadvantage  of  this  scheme,  however,  is  that  it  permits  ur 
to  compare  the  performance  of  experimental  and  control  subjects  only 
within  each  session. 

Qualitative  Analyses 

The  effect  of  individual  PRD  inputs  on  equipment  design  was  also  de¬ 
termined  subjectively,  by  asking  the  engineer  the  following  typical  ques¬ 
tions  during  the  debriefing  which  concluded  each  session; 

(1)  Does  the  new  input(s)  provide  you  with  enough  information  to 
perform  the  pa-ti-alar  design  output  required? 

(2)  Did  you  find  the  (session  PRD  input)  useful  in  performing 
today's  task? 

(3)  Could  you  apply  this  information  (i.  e.  ,  PRD  input)  to  your 
(design)  analysis? 

(4)  What  equipment  design  implications  can  you  draw  from  the 
(PRD  input)? 
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TABLE  VII 


EXPERIMENTAL  DESIGN  FOR  STUDY 


Group 


LS/H# 


Sessions 

23456789 


0  X 

X  0 

0  0 


0  0 

0  X 

X  0 


X  0 

0  0 

0  X 


HS/L# 


0  X 

X  0 

u  0 


j  0 

0  X 

X  0 


X  o 

0  0 

0  X 


Reversal  of  personnel 
requirements 


Special  problems 


Ss 

Subjects 

0 

Experimental  Subject 

X 

Control  Subject 

LS/H#  - 

Low  Skill/High  Quantity 

HS/L#  - 

High  Skill /Low  Quantity 

o  o  o  o  o  o 


During  sessions  9-10,  subjects  were  asked  to  rank  the  priority  of 
various  parameters  (e.  g.  ,  equipment  characteristics ,  cost,  reliability, 
accessibility)  to  be  considered  during  the  design  of  various  subsystems, 
and  to  rank  the  relative  importance  of  all  the  inputs  provided  to  them 
during  the  study. 

Summary  of  Experimental  Measures  of  Manpower  Requirements  and 
Personnel  Resources  tlala  Impact 


The  categories  of  experimental  measures  possible  to  answer  the 
questions  regarding  impact  of  MR  and  PRD  can  be  summarized  as  follows: 

(1)  To  determine  the  effect  of  PRD  data  on  design:  .  session-by¬ 
session  comparisons  between  all  experimental  subjects  com¬ 
bined  and  the  control  subjects. 

(2)  To  determine  the  effect  of  manpower  requirements  on  design: 

(a)  Session-by-session  comparison  between  HS/L#  and 
LS/H#  groups. 

(b)  Total  subsystem  design  comparisons  (i.  e.  ,  reliability, 
cost,  safety,  design  adequacy)  of  designs  produced  by 
HS/L#  and  LS/H#  groups. 

(c)  The  effect  of  changing  manpower  requirements  after 
subsystem  design  has  been  completed  (session  8). 

Note  that  it  is  impossible  to  make  total  subsystem  comparisons  be¬ 
tween  experimental  and  control  groups,  because  in  the  present  experi¬ 
mental  design  there  is  no  clearly  distinguishable  control  group  as  a 
group,  all  subjects  having  at  one  time  or  another  participated  in  the  study 
as  control  subjects. 

One  other  general  statement  concerning  the  experimental  design 
should  be  made.  Tests  of  significance  between  experimental  treatments 
(e.  g. ,  between  HS/L#  and  LS/H#  groups,  and  between  these  groups  com¬ 
bined  and  control  subjects)  were  not  possible  because  the  number  of 
subjects  in  any  comparison  was  never  more  than  four.  Moreover,  session- 
by-session  data  could  not  be  combined  to  increase  the  number  of  data 
points  because  each  session  involved  a  somewhat  different  design  output. 
Comparisons  between  the  various  groups  in  terms  of  their  design  outputs 
have  therefore  been  confined  only  to  reporting  of  means.  It  is,  therefore, 
necessary  to  look  for  measures  of  significance  in  terms  of  the  consistency 
of  results.  If  one  group  or  the  other  is  consistently  higher  or  lower  than 
the  other,  then  the  likelihood  that  a  genuine  phenomenon  exists. 
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The  rankings  made  by  subjects  in  sessions  9  and  19  were  tested 
for  consistency  by  the  Kendall  W  statistic  (Siegel,  1956).  The  Spearman 
rank  order  correlation  was  employed  on  one  ranking  item  (see  Table  13) 
to  determine  the  relationship  between  rankings  of  the  present  subjects 
with  those  of  the  previous  studies.  Rankings  of  the  overall  subsystem 
design  outputs  were  correlated  using  the  W  statistic. 

3.  At  What  Stage  of  Subsystem  Development  do  MR  and  PT,vD  Inputs  Have 


greatest  Input  on  Equipmen 


Because  this  study  did  not  vary  the  sequence  in  which  PRD  inputs  were 
presented  to  subjects,  it  is  impossible  to  present  any  quantitative  data  on 
this  point.  However,  if  was  possible  to  infer  the  usefulness  and  impact  of 
the  individual  PRD  inputs  as  a  function  of  stage  of  development  by  asking 
questions  such  as  the  following  at  the  conclusion  of  each  session: 

(a)  What  information  would  you  ordinarily  receive  at  this  stage  of 
system  development?  Would  this  information  be  sufficient? 

(b)  Is  the  PRD  input  (presented  at  this  session)  too  early,  too  late 
or  just  right  in  time? 

(c)  What  additional  information  would  you  want  to  have? 

(d)  If  you  knew  the  number  and  type  of  personnel  you  were  going 
to  have,  would  this  help  you  in  performing  the  design  task? 

4.  In  What  Form  are  PRD  Inputs  Most  Effectively  Used  by  Designers? 


Again,  the  information  relative  to  this  question  is  largely  qualitative. 
The  following  questions  asked  of  the  engineer  during  the  individual  session 
debriefings  are  pertinent: 

(a)  Do  you  have  any  difficulty  understanding  the  personnel  input? 
Why? 

(b)  Where  two  versions  of  the  same  PRD  input  were  presented, 
which  version  did  you  find  more  useful? 

In  addition,  one  of  the  questions  presented  during  sessions  9-10 
dealt  with  the  form  in  which  personnel  requirements  were  supplied  in  the 
design  SOW.  These  requirements  varied  in  format  from  the  qualitative 
and  general  to  the  quantitative  and  highly  specific.  Subjects  were  asked 
to  anticipate  the  impact  of  the  various  requirements  if  they  were  required 
to  design  to  these. 
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5.  What  is  the  Design  Engineer '•  Concept  of  Human  Factors  in  System 

‘Design  and  7-^ia  Attitude  'toward  Pkfj  Input? 

Quantitative  Analysis 

By  asking  the  design  engineer  to  supply  manpower  estimates  at 
session  4  and  at  the  conclusion  of  the  study,  it  is  possible  to  determine: 

(a)  If  he  had  a  concept  of  the  manning  required  by  his  subsystem 
(that  is,  whether  or  not  he  could  estimate  the  number  and  type 
personnel  needed); 

(b)  The  consistency  of  his  manning  concepts  as  additional  inputs 
were  provided; 

(c)  The  relationship  of  his  manning  concept  to  the  particular  type 
of  design  concept  he  developed? 

For  example,  it  is  possible  to  analyse  the  consistency  of  the  designer's 
manning  concept  by  determining  if  it  changed  over  the  course  of  the  study. 
The  validity  of  that  manning  concept  is  determined  by  correlating  his  de¬ 
sign  concept  (categorized  in  automation  terms  as,  completely  automated, 
partially  automated  and  remote -manual)  with  the  number  of  personnel  he 
felt  he  needed  to  man  his  subsystem.  If  the  correlation  was  high,  one  could 
say  the  engineer's  manning  concept  was  realistic;  if  it  was  low,  it  was  un¬ 
realistic. 

Qualitative  Analysis 

Engineer  attitudes  toward  PRD  inputs  and  human  factors  as  a  whole 
were  determined  by  analysis  of  subject  reactions  to  individual  PRD  inputs 
and  to  questions  asked  in  the  debriefing  sessions  at  the  conclusion  of 
individual  sessions.  In  this  respect,  it  should  be  reiterated  that  the  in¬ 
vestigator  was  not  limited  to  a  fixed  schedule  of  questions,  and  that  the 
specific  questions  asked  invariably  led  to  an  in-depth  interview. 

6.  How  Does  the  Manner  in  Which  the  Engineer  Designs  Affect  the 

- 'gnnarfftn  H"PRirTnpu!s7 - - a - - 

The  engineer's  design  style  was  determined  by  analysis  of  the  follow¬ 
ing  indices: 

(a)  The  speed  with  which  he  developed  his  initial  equipment  con¬ 
figuration; 

(b)  The  amount  and  quality  of  the  analysis  he  performed  prior  to 
and  during  the  development  of  the  equipment  configuration; 


(c)  The  nrni  be r  and  extent  of  changes  to  that  configuration  aa 
testing  progressed; 

(d)  The  design  '-riteiia  he  reported  using  as  the  basis  of  his  design; 

(e)  Expressed  attitude®  of  acceptance  or  rejection  of  PRD  inputs; 

(f)  The  practices  he  reported  as  being  characteristic  of  the  manner 
in  which  he  ordinarily  designs. 

These  were  analyzed  in  relation  to  the  following  PRD  utilization 
factors: 

(1)  Usefulness  of  the  PRD  inputs  provided; 

(2)  Timeliness  of  the  PRD  information  supplied; 

(3)  Intelligibility  of  the  PRD  information; 

(4)  Applicability  of  the  PRD  inputs  to  the  design  outputs; 

(5)  Implications  for  design  drawn  by  the  engineer  from  the  PRD 
input. 

7.  How  Available  is  Information  as  a  Whole  to  the  Engineer  During  Design? 

Data  on  this  point  was  secured  from  questions  such  as  the  following: 

(a)  Do  you  have  enough  (equipment  and  personnel)!  intormation  aoout 
(the  design  task  presented)  to  accomplish  your  task? 

(b)  What  additional  information  would  you  want  to  have  about  (the 
design  task  presented)? 

(c)  What  information  would  you  ordinarily  receive  at  this  stage  of 
system  development?  Would  this  information  be  sufficient? 

(d)  When  would  you  ordinarily  expect  to  receive  information  of  this 
nort  (e.  g.  ,  the  PRD  input)? 

(e)  Could  you  (would  you)  have  derived  this  information  (presented 
at  the  individual  session)  on  your  own? 
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SECTION  III 


RESULTS  AND  CONCLUSIONS 


A.  RESULTS 
Introduction 


Before  proceeding  to  the  specific  study  results,  it  may  be 
helpful  to  the  reader  if  he  refers  to  Appendix  III,  which  presents 
some  representative  design  outputs  which  subjects  produced  and 
which  will  give  him  a  better  >:feel"  for  the  nature  of  the  design 
procesi.  The  following  is  a  list  of  the  outputs  illustrated  in 
Appendix  III: 

(’)  Figures  12  and  13  are  two  schematic  diagrams  developed  by 
subject  K  during  the  first  session,  with  minor  changes  made 
as  simulated  development  progressed. 

(2)  Table  XV  is  a  partial  copy  of  the  equipment  description  which 
accompanies  that  flow  diagram. 

(3)  Figure  14  is  an  initial  control  panel  sketch  by  subject  D. 

(4)  Table  XVI  is  a  copy  of  a  detailed  operating  procedure  which 
accompanies  the  schematic  diagram  in  (1)  znd  the  control 
panel  sketch  in  (3). 

(5)  Table  XVII  is  a  copy  of  a  representative  list  of  hardware  com¬ 
ponents  created  by  subject  J. 

These  samples  indicate  the  rather  substantial  amount  of  detail 
to  which  the  subjects  went  in  their  design. 

Because  of  the  complexity  of  the  study  results,  w#.  will  summer 
ize  the  study  results  before  we  proceed  to  specific  details.  The 
organization  of  this  section  is  outlined  as  follows: 

A.  Summary  of  study  results: 

B.  Detailed  results  categorized  by  the  individual 
questions  which  the  study  sought  to  answer. 

Under  each  question,  then,  in  the  following 
order  the  reader  will  find 

1.  Quantitative  data  pertaining  to  the  individual 
question; 
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Z.  Qualitative  data  relevant  to  ‘hat  question; 

3,  Conclusions  reached  with  regard  to  the  question. 
Summary  of  Results 


(1)  Do  differences  in  manpower  requirements  influence  subsystem 

design"?  ” 

(a)  Session- hy-session  data  provide  somewhat  ambiguous  re¬ 
sults.  With  the  exception  of  session  4,  where  the  HS/L# 
engineers  listed  significantly  more  control -display  hard¬ 
ware  needed  to  operate  their  subsystems,  the  other 
differences  between  the  LS/H#  and  HS/L#  groups  were 
small  and  not  particularly  significant. 

(b)  Session  8  results  (in  which  personnel  requirements  were 
exchanged  between  the  LS/H#  and  HS/L#  groups)  indicated 
that  half  the  subjects  would  make  some  change  in  their 
subsystem  design,  if  not  in  the  physical  hardware  itself, 
men  in  the  subsystem  operating  procedures.  There  was, 
however,  considerable  resistance  to  the  idea  of  changing 
design  at  that  late  date,  even  though  for  LS/H#  subjects 
the  reduction  in  the  availability  of  personnel  made  their 
subsystems  inoperable. 

(c)  The  LS/H#  group  had  a  substantial  superiority  in  equip¬ 
ment  reliability  over  the  HS/L#  group,  which  may  be 
attributed  in  part  to  the  need  to  compensate  in  their  design 
for  the  requirement  to  design  the  subsystem  for  lower 
skilled  personnel. 

(d)  When  subjects  rated  (see  Table  VIII)  the  anticipated 
effect  on  design  of  various  personnel  requirements  in  the 
SOW,  those  requirements  which  were  concrete,  precise 
and  quantitative  were  rated  as  highly  influential  on  design; 
those  formulated  in  general  less  specifically  design  rele¬ 
vant  terms  were  rated  as  having  slight  or  no  effect  upon 
design. 

(e)  Apparently,  when  personnel  requirements  arc  sufficiently 
specific  to  the  new  design  and  when  they  conatrasi  design, 
they  do  have  an  important  effect  upon  that  design.  In  the 
present  study,  the  effect  of  personnel  requirements  was 
not  as  high  as  it  should  have  been  for  several  reasons: 

(l)  the  personnel  requirements  specified  in  the  experimental 
SOW  set  high  upper  limits  so  that  they  did  not  constrain 
these  subjects,  (Z)  although  subjects  indicated  that  skill 
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level  and  personnel  quantity  are  independent  parameters 
\i.  e.  .  higher  skill  level  does  not  compensate  for  fewer 
personnel  and  vice  versa),  the  combination  of  skill  level 
and  personnel  quantity  in  the  groups  tended  to  cancel  out 
their  differential  effect,  and  (3)  the  response  to  personnel 
requirements  tends  to  be  quite  idiosyncratic , 

(f)  Acting  on  the  hypothesis  that  differences  in  personnel 
requirements  should  be  reflected  also  in  engineer's  man¬ 
ning  concepts,  we  asked  subjects  to  estimate  the  manning 
needed  for  their  subsystems  during  the  fourth  session 
and  at  the  end  of  the  study. 

(g)  The  engineer  also  independently  develops  a  manning  con¬ 
cept,  in  some  cases  simultaneously  with  the  creation  of 
the  design  configuration,  in  other  cases  (developed  later), 
as  a  deduction  from  that  design  configuration.  This  con¬ 
cept  includes  both  personnel  number  and  skill  level  param¬ 
eters,  but  does  not  include  training, 

(h)  The  LS/H#  group  estimated  a  mean  of  8.  3  personnel,  and 
the  HS/L#  group  estimated  a  mean  of  6.  0  personnel,  well 
below  the  upper  limits  set  by  the  SOW  of  12.  The  results 
are  consistent  with  the  hypothesis  described  in  (a)  herein. 
In  all  cases,  during  debriefing  interviews,  subjects  re¬ 
sisted  the  idea  of  using  lesser  skilled  personnel. 

(i)  Manning  estimates  were  almost  completely  unvarying 
throughout  the  simulated  design  process.  The  QQPRI  in¬ 
put,  which  deviated  from  subjects'  estimated  manning, 
did  not  cause  them  to  change  that  manning.  As  described 
previously,  engineers  are  highly  resistant  to  suggested 
changes,  once  the  basic  subsystem  configuration  (which 
would  include  the  estimated  manning)  is  established. 

(j)  There  was  little  correlation  between  the  engineers'  man¬ 
ning  concept  and  the  type  of  subsystem  he  developed. 

For  example,  the  completely  automated  design  required 
three  times  as  many  men  as  the  semiautomated  design  and 
more  than  the  remote-manual  subsystems.  This  suggests 
that  engineers'  manpower  concepts  are  not  realistic. 

(2)  Do  Personnel  Resources  Data  Inputs  Have  a  Significant  Effect  on 

'Equipment  Design ? 
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(a)  The  primary  analysis  here  is  between  experimental 
(those  receiving  PRD  inputs)  and  control  (those  not 
receiving  PRD  inputs)  subjects  on  a  session-by-session 
baiiis.  Comparisons  between  these  groups  are  available 
for  five  sessions.  In  three  of  the  five  sessions^  the  ex¬ 
perimental  subjects  produced  a  larger  number  of  person¬ 
nel-related  design  outputs  (e.  g.  ,  larger  number  of 
control-display  hardware  items  listed)  than  the  control 
subjects.  In  one  session  (the  first)  the  difference  between 
experimental  and  control  subjects  was  essentially  zero, 
v.hile  in  another  seesion  the  difference  was  in  favor  of  the 
control  subjects.  It  appears  then  that  the  PRD  inputs  do 
have  an  effect  on  design  outputs,  but  the  effect  is  less  than 
one  would  desire. 

(b)  Expressions  of  opinion  from  the  subjects  in  debriefing 
inter-news  indicated  that  half  the  subjects  felt  that  PRD 
inputs  were  of  some  value,  while  the  other  half  did  not. 

Even  where  the  PRD  input  was  rejected  by  the  engineer, 
it  served  a  useful  purpose  as  a  reminder  of  factors  the 
engineer  may  have  overlooked  (session  5), 

(c)  Several  reasons  for  this  less  than  maximal  PRD  effective¬ 
ness  were  noted:  (1)  the  engineer  responds  to  an  input 
primarily  in  terms  of  its  importance  as  a  design  constraint; 
most  PRD  inputa  are  purely  information  or  predictive.  Half 
the  subjects  indicated  that  PRD  inputa  would  have  had  a  sig¬ 
nificant  effect  on  their  design  if  they  had  been  included  as 
requirements  in  the  SOW,  (2)  engineers  had  difficulty  inter¬ 
preting  the  significance  of  PRD  inputs  (e.  g.  ,  skill  level 
description)  in  design -relevant  terms,  and  (3)  because  the 
design  concept  is  developed  so  rapidly,  many  PRD  inputs 
supplied  in  later  design  stages  have  been  anticipated  by 
engineers. 

At  What  Stage  of  Subsystem  Development  do  MR  and  PRD  Inputs 
Have  Their  Greatest  Effect  on  Equipment  Design? 

Because  the  engineer  develops  the  hardware  details  of  his 
design  concept  so  rapidly  (the  basic  concept  was  complete  for 
all  subjects  in  session  1)  and  because  he  is  responsive  primarily 
to  design  requirements  and  constraints  (which  are  usually  in¬ 
cluded  in  the  design  statement  of  work,  to  which  all  subjects  re¬ 
ferred  most  often),  MR.  and  PRO  inputs  have  their  greatest 
impact  on  equipment  design  when  they  are  incorporated  as  part 
of  the  statement  of  work  which  initiates  that  design. 


In  What  Forms  are  PRD  Inputs  Most  Effectively  Used  by  Designers? 


(a)  The  relevant  evidence  is  derived  from  debriefings  at  the  con¬ 
clusion  of  individual  test  sessions  and  from  rankings  of  PRD 
inputs  made  in  sessions  9-10.  Although  the  most  important 
inputs  to  the  engineer  are  his  SOW  and  other  equipment  in¬ 
formation,  because  these  supply  him  with  data  on  design 
requirements  and  constraints,  the  most  important  PRD  inputs 
to  the  engineer  are  the  performance  requirements  data  on 
the  Requirements  Allocation  Sheets,  personnel -equipment 
analyses  (e.  g.  ,  control -display  memoranda),  lists  of  tasks 
and  task  descriptions.  Note  that  these  are  all  relatively 
concrete  and  intcrpretible  in  terms  of  subsystem  operations. 

A  PRD  input  is  preferr  ed  to  the  extent  that  it  describes  or 
can  be  easily  related  to  concrete  operations.  Least  useful 

to  engineers  is  information  dealing  with  training  require 
ments,  personnel  availability,  time-line  analyses,  probabil¬ 
ity  of  task  completion  and  personnel  descriptions,  because 
these  are  relatively  abstract  in  character. 

(b)  Some  of  the  same  reasons  which  determine  the  overall 
effectiveness  of  PRD  inputs  are  responsible  for  determin¬ 
ing  which  of  these  inputs  are  most  useful.  The  engineer's 
overwhelming  concentration  on  physical  parameters  and 
his  unawareness  of  human  factors  ensure  that  the  only  PRD 
inputs  he  can  use  are  those  which  can  be  most  clearly  tied 
to  physical  parameters,  e.  g.  ,  lists  of  tasks  and  task 
descriptions  which  he  interprets  as  operating  procedures; 
personnel -equipment  analyses  which  deal  with  relatively 
molecular  aspects  of  the  equipment  configuration,  etc. 

As  was  referred  to  earlier,  the  engineer  lacks  the  ability 
to  interpret  data  phrased  in  behavioral  terms,  like  skill 
level,  proficiency,  difficulty,  etc.  ,  so  that  in  order  for 
PRO  inputs  incorporating  such  concepts  to  be  accepted, 
they  must  be  rephrased  in  terms  closer  to  the  engineer's 
experience. 

What  is  the  Design  Engineer's  Concept  of  Human  Factors  in  System 

Design  and  His  Attitudes  Toward  PRD  Inputs? 

(a)  There  was  a  general  tendency  on  the  part  of  engineers  to  ig¬ 
nore  operator  considerations  in  the  very  brief  analysis 
which  preceded  his  development  of  the  subsystem  configuration. 
Because  of  the  emphasis  upon  safety,  personnel  factors  related 
to  design  for  safety  were  a  major  expressed  consideration  in 
his  design. 
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(b)  The  engineer  has  a  concept  of  the  personnel  subsystem 
as  being  largely  human  engineering  of  the  molecular 
"knobs  and  dials"  type.  Hence,  he  considers  that  most 
PRD  inputs  should  be  provided  relatively  late  in  sub¬ 
system  design. 

(c)  The  engineer  generally  considers  the  personnel  aspects 
of  the  subsystem  as  deriving  from  and  dependent  upon 
equipment  characteristics.  He  resists  the  concept  of 
personnel  resources  analysis  being  a  partner  in  the  sub¬ 
system  configuration  or  as  controlling  it  ir  any  manner. 

How  Does  the  Manner  in  Which  the  Engineer  Designs  Affect  the 

Utilization  of  PkjL)  Inputs?  ~ 

(a)  Most  important  in  terms  of  its  effect  upon  the  engineer's 
use  of  PRD  is  the  excessive  speed  with  which  he  proceeds 
to  develop  his  design  concept.  In  every  case,  this  concept 
was  fully  developed  by  the  end  of  the  first  test  session. 

The  consequences  of  the  speed  with  which  he  develops  the 
hardware  details  of  his  design  are  that  the  system  analytic 
process,  during  Mch  human  factors  involved  in  the  design 
would  be  coni  ider_  i,  is  highly  compressed,  so  that  in  fact 
there  i a  little  or  no  consideration  of  human  resources 
problem  8. 

(b)  That  the  initial  system  concept  is  modified  in  only  very 
minor  details  as  design  progresses  is  also  quite  important. 
Consequently,  most  of  the  PRD  supplied  after  the  start  of 
design  are  essentially  irrelevant  to  the  engineer.  PRC  can 
either  coincide  with  the  engineer's  system  concept,  in 
which  case  they  serve  merely  to  reinforce  that  concept, 

or  they  will  conflict  with  that  concept,  in  which  case  they 
will  be  ignored  or  rejected. 

(c)  The  major  reasons  for  the  speed  with  which  the  engineer 
designs  is  his  reliance  on  his  past  experience  and  his  use 
of  the  design  stereotypes  which  he  brings  to  the  design 
problem. 

(d)  The  engineer  relies  primarily  on  inputs  which  are  inter¬ 
preted  by  him  either  as  design  requirements  or  design 
constraints.  Thus,  the  major  information  source  for  the 
engineer  is  the  SOW  and  associated  equipment  information. 
Hence,  PRD  which  cannot  be  interpreted  in  this  manner 
are  ignored. 
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Because  the  engineer  designs  primarily  in  terms  of 
requirements  and  constraints,  many  engineers  resist 
the  introduction  of  information  which  may  constrain 
his  design.  The  following  antithetical  attitudes  are 
expressed  according  to  the  engineer's  characteristic 
design  style:  either  he  prefers  to  receive  as  much 
information  as  possible  as  a  guide  to  his  design  or  he 
resists  what  he  considers  excessive  information  as 
limiting  his  creative  freedom. 

The  subsystem  designs  produced  by  the  engineer -subjects 
show  considerable  variations  in  basic  design  concept. 

These  differences  are  due  to  a  number  of  factors:  (1) 
variation  in  the  manner  in  which  the  originating  design 
SOW  is  interpreted,  in  terms  of  the  priorities  placed  on 
design  criteria  described  in  the  SOW,  such  as  cost, 
safety,  reliability,  and  (2)  the  experimental  stereotypes 
he  possesses,  such  as  rejection  of  automated  systems 
(in  general)  or  rejection  of  manual  systems  (in  general). 

The  major  differences  in  design  are  reflected  in  differ¬ 
ences  in  equipment  and  personnel  reliability,  safety  and 
cost. 

Three  kinds  of  subsystem  designs  were  developed:  (1) 

Four  of  the  six  could  be  described  as  rer-.ote  manual; 
one  as  semiautomated  and  one  as  completely  automated. 
Three  of  the  four  remote  manual  systems  were  developed 
by  the  HS/L#  group;  the  two  automated  systems  uy  the 
LS/H#  group.  However,  these  differences  cannot  te 
ascribed  to  varying  personnel  requirements,  but  rather 
to  the  way  the  individual  engineers  interpreted  the  SOW. 

The  design  criteria  which  the  engineer  typically  applies 
in  his  design  are  indicated  by  ranking  supplied  by  sub¬ 
jects  in  Item  9-1  (see  Tabic  XII).  In  order  of  decreasing 
importance,  these  are:  physical  equipment  characteristics, 
reliability,  cost,  complexity  of  operating  procedures  and 
the  effect  of  equipment  :haractei  ietics  ou  personnel. 

The  foregoing  design  process  characteristics  are  startingly 
similar  to  characteristics  observed  with  the  30  engineers 
tested  in  the  two  previous  studies  Dy  Meister  and  Farr  (1966) 
and  Meister  and  Sullivan  (1967). 
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(7)  How  Available  is  Information  as  a  Whole  to  the  Engineer  During 
Design? 

(a)  Design  engineers  usually  have  less  information  han  was 
provided  them  in  the  study.  This  was  particularly  true 

of  PRD  information.  Engineers  generally  prefer  as  much 
equipment-related  information  as  possible,  and  as  early 
as  possible,  but  this  is  true  of  PRD  inputs  only  in  the  case 
of  certain  subjects. 

(b)  In  the  subjects'  opinions,  the  information  provided  them 
in  the  study  was  more  than  sufficient  for  them  to  accom¬ 
plish  their  design  tasks.  The  only  exception  to  this  was 

a  lack  of  detail  describing  the  characteristics  of  the  *pace 
launch  vehicle. 

(c)  Engineers  felt  that  they  could  have  developed  certain  types 
of  PRD  information  on  their  own,  e.g.  ,  personnel/equip¬ 
ment  analyses  and  task  data,  i.  e.  ,  information  closely 
related  to  the  equipment  functioning  of  the  subsystem. 
However,  they  would  not  and  could  not  have  developed 
QQFRI  on  their  own. 


Detailed  Results 

1.  Do  Ditferences  in  Manpower  Requirements  Influence  Subsystem 
Configurations? 


The  six  subjects  were  divided  into  two  groups  which  received  different 
manpower  requirements  in  their  design  SOW  The  LS/H#  group  received 
the  instruction  that  they  minimize  the  skill  required  of  operating  personnel, 
even  if  it  necessitated  a  larger  number  of  personnel.  Subjects  in  the  HS/L # 
group  were  required  to  minimize  the  number  of  operating  personnel  even  if 
it  necessitated  an  increased  skill  level. 

Quantitative  Results:  Session-by-Session  Measures 

Measures  of  the  effect  of  manpower  requirements  on  the  design  outputs 
of  the  two  groups  are  available  from  session-by-session  analyses.  These 
results  arc  based  on  all  six  subjects,  since  presumably  the  differing  man¬ 
power  requirements  were  effective  even  when  control  subjects  received  no 
PRD  inpu.s. 

It  was  hypothesized  that  the  HS/L#  group  would  include  in  their  sub¬ 
system  design  a  greater  number  of  manual  functions  than  would  the  LS/H# 
group,  because  the  former  engineers  would  have  more  confidence  in  the 
ability  of  higher  skilled  personnel  to  perform  subsystem  control  tasks. 
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This  hypothesis  assumed  that  a  larger  quantity  of  personnel  would  not  be 
considered  by  the  engineers  of  the  LS/H#  group  as  compensating  for  the 
lesser  skill  of  the  personnel  available  to  these  designers.  Consequently, 
the  LS/H#  engineers  would  be  more  inclined  to  automate  their  subsystems. 

(1)  Session  1.  Differences  in  number  of  personnel-related  functions, 
e.  g.  /  manual  interfaces,  and  primarily  manually  operated  valves 
specified  in  the  schematics  produced  by  the  two  groups: 


HS/L#  LS/H# 


s 

No.  of  Functions 

s 

No.  of  Functions 

1 

7 

1 

10 

2 

4 

2 

3 

3 

- 

3 

3 

8 

Total 

T? 

Total 

7T 

M 

4.7 

M 

7.0 

The  small  number  of  subjects,  as  also  the  small  number  of 
functions  (perfectly  understandable  at  this  gross  level  of  system 
description),  makes  it  impossible  to  draw  any  meaningful 
statistical  conclusions  from  the  data.  The  differences  do  not 
appear  to  be  significant,  however.  These  differences  are  largely 
due  to  the  degree  to  which  the  individual  engineer  initially  detailed 
his  design. 

(2)  Sessions  2-3.  In  sessions  2-3,  subjects  were  required  to  describe 
the  equipment  which  they  would  need  to  implement  their  design 
concept.  Again,  the  number  of  personnel-related  equipment  items 
(e.  g.  ,  manually  operated  valves)  which  they  required  is  of  interest. 

The  mean  number  of  items  noted  by  tne  HS/L#  group  is  58.  7;  the 
mean  number  for  the  LS/H#  group  is  68.  9.  The  individual  values 
are  listed  below: 


HS/L#  _ _ LS/H# 


S  _ No.  of  Items  _ S  No.  of  Items 

1  35  1 

2  59  2 

3  3 

M  58. 7 


43 

70 

91 

M  68.  0 
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Again,  because  of  the  small  number  of  subjects  in  each  group, 
any  statistical  comparisons  would  be  meaningless.  However, 
these  differences  do  not  appear  to  be  significant,  again  for  the 
same  reason  cited  previously  for  session  1. 

Session  4.  In  this  session,  subjects  were  asked  to  list  the  con- 
trol  display  hardware  needed  to  run  their  systems.  It  is,  there¬ 
fore,  possible  to  compare  the  two  groups  in  terms  of  the  number 
of  control -display  hardware  items  they  required.  The  results 
are  shown  below; 


HS/L# 

LS/H# 

s 

No.  of  Items 

S 

No.  of  Items 

1 

250 

1 

50 

2 

50 

2 

142 

3 

185 

3 

118 

M  161.7 

M  103.3 

The  difference  here  in  contrast  to  the  previous  three  sessions, 
is  quite  substantial,  but  again  the  small  number  of  subjects 
prevents  meaningful  statistical  comparison  of  the  two  groups. 
The  two  subjects  who  responded  with  only  50  items  were  con¬ 
trol  subjects  (i.  e.  ,  those  who  had  not  received  the  PRD  input 
for  that  session).  When  control  subjects  are  eliminated,  the 
difference  is  even  greater,  HS/L#  subjects  having  a  mean  of 
217  items,  and  LS/H#  subjects  having  a  mean  of  130  items. 

It  is  necessary  to  explain  why  the  differences  between  the  two 
groups  in  session  4  are  so  great  in  contrast  to  the  small  dif¬ 
ferences  noted  in  previous  sessions;  and  why  the  HS/L#  group 
produced  more  control  display  hardware,  when  in  previous 
sessions  they  had  had  fewer  subsystem  functions  and  manually 
operated  valves. 

As  indicated  previously,  it  is  hypothesized  that  the  HS/L#  group 
felt  it  could  assign  more  manual  tasks  to  its  small  number  of 
personnel  because  these  personnel  were  highly  skilled.  Conse¬ 
quently,  they  permitted  their  technicians;-  to  perform  their  tasks 
manually  (i.  e.  ,  by  switching  controls  in  response  to  subsystem 
display  indications)  whereas  the  LS/H#  group  felt  that  they  had 
to  automate  subsystem  processes  more  because  lower  skilled 
personnel  could  not  be  relied  on.  Since  the  HS/L#  group  de¬ 
signed  their  subsystem  so  that  its  control  processes  were  to  be 


performed  manually,  they  had  to  include  a  substantially 
greater  number  of  controls  and  displays  to  accommodate 
these  manual  tasks. 

The  apparent  reve*eR.l  between  the  results  of  session  4  and 
sessions  1-3  (the  n#  group  producing  a  high  number  of 
personnel  i elated  equipment  in  session  4,  whereas  they 
produced  a  low  number  in  sessions  1-3)  is  accounted  for 
by  the  fact  that  the  listing  of  control-display  hardware  is  a 
much  more  direct,  sensitive  measure  of  response  to  man¬ 
power  requirements  than  is  the  listing  of  subsystem  func¬ 
tions  and  manually  operated  valves  which  are  tiod  only 
indirectly  to  manpower  requirements.  The  manual  valves 
were  required  by  all  engineers  because  only  in  this  way 
can  propellants  from  the  storage  tanks  to  the  launch  vehicle 
could  be  performed  in  different  ways  depending  on  the  degree 
of  automation  in  the  design  concept. 

(4)  Session  5.  In  session  5,  subjects  were  presented  with 

maintenance  functions  and  tasks  and  asked  to  indicate  the 
maintenance/test  equipment  they  would  require  to  implement 
their  systems.  It  was  hypothesized  that  the  group  more  re¬ 
sponsive  to  personnel  requirements  would  list  more  test 
equipment.  When  the  two  groups  are  compared  in  terms  of 
the  number  of  maintenance /test  equipment  items  listed  in 
the  equipment  descriptions,  the  following  appears: 


HS/L# 

LS/H# 

s 

No.  of  Items 

S 

No.  of  Items 

1 

0 

1 

2 

2 

3 

5 

3 

1 

3 

1 

M  1.3 

M  2. 7 

The 

essential  infer  nation 

which  one 

can  derive  from  session  5 

is  that  subjects  were  not  particularly  maintenance  conscious, 
as  evidenced  by  the  low  number  of  items  they  produced  (one 
subject  requiring  none).  The  difference  between  the  two  groups 
cannot,  therefore,  be  considered  significant,  even  though  the 
LS/H#  group  produced  twice  as  many  items  oi  test  equipment 
as  the  HS/L#  group.  The  larger  number  of  test  equipment 
items  for  the  LS/H#  group  was  due  largely  to  one  roan  (subject 
H)  who  designed  the  only  completely  automated  subsystem  and 
who  might,  therefore,  be  expected  to  be  more  concerned  about 
maintenance. 
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Sessions  6A  and  6B.  The  outputs  of  these  sessions  were 
de signecT to  be  used  for  analysis  of  the  total  subsystem  design; 
hence  they  will  be  discussed  later. 

Session  7A.  In  session  7A,  subjects  were  asked  to  list  the 
operating  problems  they  could  anticipate  in  the  functioning  of 
their  subsystems.  A  comparison  can  be  made  between  the  two 
groups  in  terms  of  the  number  of  personnel-related  problems 
noted  by  subjects.  This  is  shown  below; 


HS/L# 

LS/H# 

S 

No.  of  Problems 

S 

No.  of  Problems 

1 

7 

1 

6 

2 

18 

2 

9 

3 

12 

3 

_9 

M  12.  3 

M  8.  0 

The  increased  number  of  operating  problems  noted  by  the  HS/L# 
group  can  be  explained  in  terms  of  the  larger  number  of  manual 
functions  (see  results  of  session  4)  which  this  group  included  in 
their  subsystem  design.  Since  personnel  were  used  by  this 
group  to  control  the  subsystem  diiectly  (by  switch  operations, 
on  the  basis  of  displayed  information),  it  could  be  assumed  that 
more  operating  problems  would  arise  in  this  situation  than  in 
the  LS/H#  designs  where  control  operations  were,  despite  the 
larger  number  of  personnel,  more  automated. 

Session  8.  Session  8  results  will  be  evaluated  in  the  qualitative 
subsection  of  this  analysis,  since  the  outputs  produced  during 
this  session  do  not  lend  themselves  to  quantitative  evaluation. 

Sessions  9-10.  Only  one  of  the  items  presented  in  these  two 
sessions  is  relevant  to  the  question  of  the  influence  of  person 
nel  requirements  in  the  SOW. 

Fourteen  statements  representing  requirements  of  varying 
degree  of  concreteness,  specificity  and  quantity  were  presented. 
Subjects  were  required  to  indicate  whether  the  individual  state¬ 
ment  would  (1)  greatly  affect  design,  (2)  slightly  affect  design, 
and  (3)  h« . ..  no  effect  on  design.  Unfortunately,  subject  con¬ 
sistency  failed  to  be  significant  when  tested  with  Kendall's  W 
at  the  .  05  level.  Thirteen  of  these  statements  described  various 
types  of  PRD,  e.  g.  ,  personnel  availability,  maximum  number 
of  personnel  permitted,  training,  etc. 


TABLE  VIII 


RATINGS  BY  SIX  DESIGNERS  OF  THE  INFLUENCE  OF 
VARIOUS  TYPES  OF  PERSONNEL  REQUIREMENTS  UPON  DESIGN 


Item  No. 


1 


2 


3 

4 


5 

6 


Number  of  Responses 
in  each  Category  * 

1  II  III 


Requirement 


6 


In  crder  to  avoid  safety  problems,  all 
subsystem  operations  will  be  performe 
from  a  remote  control  station. 


d 


6 

6 

6 


5 


For  reasons  of  economy,  all  subsystem 
operations  will  be  performed  manually, 
consistent  with  safety  provisions. 

Subsystem  design  and  production  of  the 
initial  system  cannot  exceed  $200,000, 

The  following  subsystem  operations  will 
be  performed  msnually:  transfer  of 
propellant  from  the  railroad  car  to  the 
RSV;  control  of  propellant  temperature; 
the  addition  or  removal  of  incremental 
amounts  of  propellant  to  "top"  the  roc¬ 
ket  tanks;  return  of  propellant  from  the 
rocket  tasks  to  the  RSV;  flush  and  purge 
of  the  subsystem. 

The  maximum  number  of  personnel  in 
the  system  operating  crew  will  be  two. 


5 


Because  of  the  nonavailability  of  exper¬ 
ienced  personnel,  it  is  required  that 
all  tasks  with  a  difficulty  index  of  two 
or  more  shall  be  performed  by  auto¬ 


matic  means. 


7 

8 


l 


2  4  A  maximum  of  18  personnel  will  be 

available  for  the  operating  crew. 

3  2  1  The  subsystem  will  be  operated  by  Air 

{•  or;  e  personnel  with  no  prior  experience 
except  a  three  -  months  course  in  missile 
o  pe  r  a  t  ion  s 


Subjects  were  requ;reu  to 
(I)  Greatly  affect  design, 
de  sign. 


indicate  whether  the  individual  statement  wo 
ijp  yhtiv  affect  design.  (Ill)  Have  no  affect 


ild: 

on 


TABLE  VIII 


RATINGS  BY  SIX  DESIGNERS  OF  THE  INFLUENCE  OF 
VARIOUS  TYPES  OF  PERSONNEL  REQUIREMENTS  UPON  DESIGN 


Number  of  Responses 
in  Each  Category* 

Requirement 

Item  No. 

I  II  III 

9 

1  s 

The  subsystem  will  be  operated  by  Air 

Force  personnel  with  an  AFSC  3  skill 
level. 

10 

6 

The  subsystem  will  be  operated  by  Air 

Force  personnel  with  a  7  AFSC  skill 
level. 

1 1 

1  2  3 

The  capability  of  Air  Force  personnel 
to  operate  the  subsystem  will  be  dem¬ 
onstrated  over  a  minimum  ol  20  oper¬ 
ating  cycles.  No  more  than  one  e^ror 
in  each  operating  cycle  will  be  per¬ 
mitted. 

12 

1  1  4 

The  satisfactory  condition  of  all  sub 
system  operations  performed  by  per¬ 
sonnel  will  be  verified  by  one  or  more 
monitoring  personnel  before  the  next 
subsystem  function  can  be  initiated. 

13 

1  5 

All  Air  Force  personnel  who  will  even¬ 
tually  operate  the  subsystem  will  be 
trained  and  their  capability  to  perform 
verified  by  the  contractor  before  being 
permitted  to  operate  the  subsystem 
without  supe  r  vis  ion. 

14 

6 

J _ 

It  is  anticipated  that  phas  ng  out  of 

Titan  I  operational  squadron  will  make 
available  a  supply  of  personnel  trained 
to  operate  and  maintain  the  subsystem. 

Subjects  were  required  to  indicate  whether  the  individual  statement  would- 
(I)  Greatly  affect  design,  (II)  Slightly  affect  design,  (III)  i’ave  no  affect  on 
desi  gn. 
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Leaving  out  the  third  item  in  the  table  (which  refers  to  a  cost 
constraint)  as  not  being  relevant  to  the  question,  it  is  apparent 
that  for  five  oi  ths  manpower  requirements  (Items  1,  2,  4,  5 
and  6),  at  least  five  of  the  subjects  considered  that  the  poten¬ 
tial  effect  of  the  requirement,  if  included  in  the  SOW  would  be 
to  greatly  affect  design.  Nine  of  the  13  requirement  (Items 
1,  2,  4,  5,  6,  7,  8,  9,  and  10)  wire  considered  by  subjects  o 
either  greatly  or  slightly  affect  design.  The  other  four  man¬ 
power  requirements  (Items  11-14)  were  considered  by  at  least 
five  of  the  six  subjects  to  have  no  effect  on  design.  These  four 
requirements  were  the  ones  which,  when  the  requirements  were 
developed  initially,  were  deliberately  made  most  general  and 
were  phrased  in  informational  terms  only;  they  deal  with  rela¬ 
tively  abstract  concepts  (e.  g.  ,  personnel  availability,  training, 
etc. ). 

Are  these  data  the  result  of  pure  chance?  The  answer  can  be 
derived  by  testing  the  distribution  of  responses  across  the 
three  categories  by  use  of  the  Chi-square  statistic. 

If  thede  responses  occurred  by  chance,  the  total  number  of 
responses  in  each  category  would  be  26  (i.  e. ,  number  of  sub¬ 
jects,  6,  times  number  of  statements,  13,  divided  by  the  num¬ 
ber  of  categories,  3).  The  distribution  of  responses  in  each 
category  is  as  follows: 


_ i  ii  m 

Actual  36  23  19 

Expected  26  26  26 

It  is  apparent  that  one  must  reject  the  hypothesis  of  responses 
distributing  themselves  across  the  three  categories  by  chance 
at  the  5%  level.  Chi-square  equals  6.  04,  5.  9'3  being  required 
for  significance  at  the  .  05  level.  One  can  say  then  with  a  fair 
degree  of  confidence  that  when  PRD  state ments  are  phrased 
precisely,  as  requirements,  and  are  xelevant  to  concrete  sub¬ 
system  operations  (e.  g.  ,  I  terns  1,  2,  4,  5  and  6),  they  will 
influence  design  greatly;  on  the  other  hand,  when  PRD  inputs 
are  nonspecific  and  deal  with  what  to  the  engineer  are  relatively 
abstract  concepts,  (e.  g.  ,  Items  11-14),  they  will  nave  no 
influence  on  design. 
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(9)  Overall  subsystem  design  comparisons.  Each  engineer's  sub¬ 
system  design  was  evaluated  In  terms  of  equipment  reliabiiitv, 
numan  reliability,  safety,  design  adequacy  and  cost.  The  com¬ 
parisons  are  shown  in  Table  IX. 

The  first  thing  one  wishes  to  know  is  how  consistent  these  eval¬ 
uations  are  (e.g.  ,  whether  the  five  evaluations  correlate  sig¬ 
nificantly  with  each  other). 

Kendall's  W  measure  of  consistency  indicates  ti»ut  the  rankings 
of  the  various  parameters  which  enter  into  overall  subsystem 
effectiveness  are  not  significantly  consistent  (W  ~  .  24), 

Certain  of  the  parameters  are,  however,  highly  correlated,  i.  e.  , 
equipment  reliability,  human  reliability,  and  safety.  The  lack 
of  overall  consistency  may  result  from  the  subjective  elements 
entering  into  the  safety  and  design  adequacy  evaluations,  or  it 
may  be  that  the  various  aspects  of  system  effectiveness  cannot 
be  combined  to  form  a  single  measure. 

Nevertheless,  for  the  extremes  r.f  the  design  distribution,  the 
agreement  among  the  measures  is  quite  marked.  The  design 
(subject  H)  found  to  be  most  reliable  from  an  equipment  stand¬ 
point  is  also  most  reliable  from  a  personnel  itandpomt  and  has 
second  ranking  from  a  safety  and  dcsi.;'  ado  ]uacy  standpoint. 
Significantly,  this  design  ia  tne  most  costlv  f-\Mch  is  quite 
understandable). 

Subject  K's  design,  which  is  le»6t  reliable  from  an  equipment 
standpoint  is  rated  as  least  adeqiateiy  designed  and  almost  as 
costly  as  subject  H's. 

In  terms  of  differences  between  the  two  groups,  the  LS/H# 
group  has  a  mean  equipment  reliability  of  .  9648,  whereas  the 
HS/L#  group  has  a  mean  equipment  reliability  of  .  q267.  Al¬ 
though  any  statistical  test  of  these  differences  would  be  mean¬ 
ingless  with  an  N  of  3,  it  is  apparent  that  if  the  same  range  of 
differences  were  reflected  in  a  larger  group  of  engineers,  the 
difference  between  the  two  groups  would  be  highly  significant. 

The  difference  in  equipment  reliability  may  be  a  reflection  of 
the  same  factors  which  caused  the  HS/L#  ftroup  tc  incorporate 
mere  manual  tasks  in  their  subsystem:  the  tact  that  they  were 
required  to  design  for  a  more  highly  skilled  set  of  operators 
may  have  led  them  to  da  sign  a  less  automated  subsystem  and 
this  in  turn  produced  a  lower  mean  eouioment  reliability.  On 
the  other  hand,  the  greater  automation  found  in  the  designs  of 
the  LS/H#  group  (a  reflection  of  the  fact  that  they  were  required 


67 


to  design  for  lesser  skilled  personnel)  could  have  resulted  in 
higher  reliability.  This  is  a  point  which  needs  further  investi¬ 
gation  and  is  raised  here  largely  as  a  reasonable  hypothesis. 

The  differences  between  the  two  groups  in  terms  of  human  re¬ 
liability  are  even  more  striking  than  are  those  of  equipment 
reliability.  The  mean  human  reliability  for  the  LS/H#  group 
was.  3479;  that  of  the  HS/L#  group  was  .  7252.  This  difference 
cannot  but  be  highly  significant. 

If  we  make  the  same  hypothesis  as  before,  that  the  LS/H?  group 
automated  their  designs  to  compensate  for  their  lesser  ...  .lied 
personnel,  then  the  higher  human  reliability  of  this  group  re¬ 
sults  from  deliberately  removing  the  opportunity  for  human 
error  by  eliminating  manual  functions.  The  converse  of  this 
would  also  seera  to  be  reasonable:  the  lower  human  reliability 
of  the  HS/L#  group  resulted  from  the  inclusion  in  their  sub¬ 
system  designs  of  more  manual  tasks,  thus  permitting  a  greater 
opportunity  for  human  error. 

The  human  reliability  results  do  suggest  the  important  influence 
of  manpower  requirements.  These  results,  however,  should  not 
be  interpreted  to  mean  that  a  better  subsystem  design  is  automat¬ 
ically  produced  by  eliminating  human  functions.  The  human  re¬ 
liability  measure  is  directly  responsive  to  the  number  of  manual 
tasks  only  and  does  not  take  into  account  the  probability  that  more 
highly  skilled  personnel  would  be  less  likely  to  make  errors,  even 
when  they  had  a  greater  opportunity  to  do  so. 

The  differences  between  the  two  groups  in  terms  of  safety  are 
obviously  so  slight  as  to  be  insignificant.  The  difference  in  mean 
ranking  for  design  adequacy  between  the  two  groups  is  also  so 
slight  as  to  be  meaningless:  3.  3.  for  the  HS/L#  group,  3.  6  for 
the  LS/H#  group.  Costs  for  the  subsystems,  when  distributed 
by  group,  are  almost  identical:  the  HS/L#  group  having  a  mean 
of  $789,  000,  the  LS/H#  group  having  a  mean  of  $788,  000. 

What  do  these  results  imply?  Manpower  requirements  do  seem  to  have  an 
influence  on  equipment  and  human  reliability,  Out  none  on  safety,  design  and 
cost.  One  possible  reason  for  the  fact  that  the  latter  indices  failed  to  dif¬ 
ferentiate  the  two  groups  is  that  they  depend  on  rather  global,  subjective 
rankings  which  may  be  comparatively  insensitive  to  fine  design  variations. 

The  effect  of  manpower  requirements  on  system  effectiveness  measures 
is,  however,  probably  not  direct. 

The  effect  ot  any  set  of  requirements,  whether  these  be  cost,  reliability 
or  personnel  resources,  is  filtered  through  a  medium  or  barrier  which 
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attenuates  the  influence  of  those  requirements.  This  medium  or  barrier 
is  what  has  been  termed  in  this  report  the  engineer's  idiosyncratic 
"design  style."  That  design  style  consists  of  the  engineer's  interpretation 
of  the  initial  set  of  requirements  and  the  established  means  he  has  of  im¬ 
plementing  those  requirement?  through  design.  If  the  initial  requirements 
were  not  modified  by  the  engineer's  interpretation  of  their  relative  impor¬ 
tance,  and  the  means  he  employs  to  implement  them,  their  effect  on  the 
equipment  configuration  would  probably  be  greater. 

This  can  be  clarified  by  reference  to  some  individual  subject  examples. 
The  advantage  in  mean  equipment  reliability  of  group  LS/H#  was  consid¬ 
erably  assisted  by  subject  H,  whose  subsystem  had  the  highest  reliability. 
Why?  H's  design  was  that  of  a  completely  automated  subsystem  involving 
the  use  of  two  computers,  one  for  backup.  The  reason  H  went  to  such  a 
design  configuration  was  not  particularly  that  he  was  influenced  by  the 
personnel  requirements  expressed  in  the  SOW  (although  the  constraint  of 
having  lower  skilled  personnel  in  his  crew  may  well  have  reinforced 
already  existent  design  attitudes  within  him),  but  because  he  viewed  the 
time  and  reliability  requirement  in  the  SOW  as  more  important  than  any 
other.  He  felt  he  could  not  meet  the  time  and  reliability  requirements 
in  any  way  other  than  by  automation.  His  interpretation  of  the  severity 
of  the  time  and  reliability  requirements  was  not  shared  by  the  other 
engineers.  With  his  idiosyncratic  design  style,  Subject  H  proceeded  to 
design  a  completely  automated  subsystem  with  special  provisions  against 
the  possibility  of  failure,  either  of  equipment  or  personnel.  Hence,  his 
high  reliability  and  equally  high  cost. 

Other  subjects  had  other  design  styles.  .Subject  K  and  several  others 
believed  just  as  strongly  in  manual  as  opposed  to  automatic  systems. 
Subject  K  also  interpreted  the  high  reliability  requirement  in  the  SOW  as 
being  of  top  priority,  but  solved  that  problem  by  including  redundant  com¬ 
ponents  rather  than  automaticity  in  his  subsystem.  K's  increased  num¬ 
ber  of  components  cost  him  dearly  in  terms  of  equipment  reliability  and 
almost  as  much  in  terms  of  money. 

Attention  must,  therefore,  be  drawn  to  the  necessity  of  clearly  ex¬ 
plaining  the  priority  to  be  accorded  to  design  criteria  ;n  the  SOW.  If 
cost  is  the  essential  factor  in  a  subsystem,  this  must  be  indicated  beyond 
any  shadow  of  doubt.  The  same  is  true  of  other  design  criteria.  It  does 
not  help  the  procuring  activity  to  get  the  system  it  desires  to  include 
equivocal  statements  such  as,  "The  system  will  be  designed  to  the  highest 
possible  reliability  commensurate  with  cost,"  or  "The  system  shall  be 
designed  to  minimize  the  possibility  of  human  error,  within  cost  and  re¬ 
liability  limitations."  Such  vague  statements  will  force  the  engineer  to 
apply  his  own  design  criteria  and  design  strategy  which  may  or  may  not 
coincide  with  those  of  the  procuring  agency.  Possibly,  the  procuring 
activity  should  apply  an  ordinal  scale  of  priorities  to  the  several  require¬ 
ments  in  the  SOW,  Tradeoi.s  between  cost  and  reliability,  cost  and  per¬ 
sonnel  requirements,  etc.  ,  should  be  clearly  indicated  in  the  SOW. 
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From  the  standpoint  of  personnel  requirements,  which  are  "foreign 
territory"  to  most  design  engineers,  these  requirements  must  be 
phrased  unequivocably  and  mphatically.  General  statements  reflecting 
design  goals  such  as,  "The  system  shall  be  designed  to  take  maximum 
advantage  of  personnel  capabilities'1  are  practically  meaningless  to  the 
design  engineer  (and  even  to  the  personnel  specialist).  The  explication 
of  personnel  requirements  in  the  SOW  may  not  completely  overcome  the 
effect  of  the  engineer's  peculiar  design  style  and  strategy,  but  it  will 
mitigate  its  effects. 

Qualitative  Analysis 

Another  way  to  determine  the  effect  of  personnel  requirements  on 
design  was  to  reverse  the  requirements  for  the  two  groups  in  session  8. 
Subjects  of  the  LS/H#  group  arbitrarily  had  the  number  of  personnel  they 
had  assigned  themselves  cut  approximately  in  half  (e.  g.  ,  from  12  to  6), 
and  the  skill  level  of  the  reduced  crew  was  substantially  increased. 

Subjects  of  the  HS/L#  group  had  their  estimates  of  the  number  of  person¬ 
nel  available  to  them  increased  significantly  (e.  g,  ,  doubled  or  tripled 
depending  on  the  original  estimate  the  engineer  had  made),  and  the  skill 
level  of  the  new  personnel  reduced  substantially. 

These  changes  in  quantitative  and  qualitative  manning  produced  changes 
in  equipment  design,  but  certain  subjects  strenuously  resisted  design  mod¬ 
ifications.  The  flavor  of  the  subject  responses  can  be  seen  in  the  follow¬ 
ing: 

High  Skill/Low  #  Group 

(1)  Subject  K.  He  estimated  7;  this  was  upped  to  15.  This  subject 
Telt  that  the  addition  of  personnel  would  not  compensate  for  their 
reduced  skill  level.  In  terms  of  what  he  would  do  to  modify  his 
design,  he  indicated  he  would  change  his  procedures;  make  them 
more  inflexible,  more  proceduralized  (step  by  step),  with  noth¬ 
ing  left  to  the  imagination.  He  might  tend  to  automate  more,  but 
felt  that  cost  would  negate  this. 

(2)  Subject  D.  Estimated  8;  upped  to  15.  This  subject  felt  the  change 
was  unreasonable  but  normal  for  system  development.  He  would 
make  changes  only  in  the  control  area;  would  add  some  displays 
and  would  eliminate  checklists.  He  felt  that  the  lowered  skill 
level  would  require  a  more  automatic  system  hence  he  would  add 
more  interlocks. 


(3)  Subject  J.  Estimated  3;  upped  to  10.  This  subject  felt  that  the 
change  In  manning  would  not  affect  his  design,  because  it  was 
already  automatic  and  the  automaticity  was  required  because 
of  the  reliability  requirement. 

Low  Skill/High  #  Group 

(1)  Subject  H.  Estimated  9;  cut  to  6.  This  subject  felt  that  the 
change  was  unreasonable  and  that  he  could  not  maintain  the 
system  with  the  reduced  number  of  personnel.  However,  he 
would  not  change  his  design  configuration. 

(2)  Subject  N.  Estimated  4;  cut  to  2.  This  subject  felt  that  the 
system  could  be  operated  by  two  people,  but  one  would  have  to 
do  away  with  the  "buddy  system"  (i.e,  ,  the  requirement  that 
all  personnel  operations  be  performed  by  two  men).  He  would 
not  change  the  physical  design  configuration. 

(3)  Subject  S.  Estimated  12;  cut  to  6.  This  subject  would  not  change 
his  equipment  configuration  because  of  the  change  in  skill  level. 
Since  he  had  already  designed  the  equipment  for  lower  skilled 
people,  more  skilled  personnel  would  be  able  to  operate  it.  How¬ 
ever,  he  might  modify  the  mechanical  layout  of  his  equipment, 
i.e.,  centralize  his  control  functions.  He  might  change  his  con¬ 
trol/display  layout  to  be  operated  by  two  people,  rather  than 
four.  He  would  also  put  in  a  loudspeaker  system  to  facilitate 
communication. 

It  is  apparent  that  some  of  the  design  engineers  strenuously  resisted 
the  modified  manpower  requirements,  not  only  in  session  8  but  also  in 
debriefing  interviews  following  the  individual  test  sessions.  Several 
conclusions  are  possible: 

(1)  Personnel  requirements  do  have  some  influence  on  hardware 
design.  However,  when  they  are  imposed  on  an  already  estab¬ 
lished  design,  their  effects  are  not  manifested  in  the  basic 
design  concept  which  remains  intact,  but  on  peripheral  aspects 
(e.  g.  ,  controls  and  displays,  communications,  procedures). 

The  implication  is  that  for  personnel  requirements  to  have  suf¬ 
ficient  influence  on  the  basic  design  concept,  they  must  be 
provided  at  or  before  the  tim  *  that  design  concept  is  developed. 
This  is  reinforced  by  subjects'  statements  to  essentially  the 
same  effect. 

(2)  Once  he  had  created  his  design,  the  engineer  resists  the  effect 

of  personnel  requirements  to  the  point  of  denying  the  obvious  need 
for  a  redesign.  This  implies  that  if  the  requirement  had  been 
specified  initially  (before  the  design  concept  was  developed),  it 
would  have  been  accepted  more  gracefully.  In  other  contexte, 
this  statement  was  made  by  a  number  of  engineers. 
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(3)  Engineers  do  not  feel  additional  personnel  compensates  for 
reduced  skill  level.  Thus,  four  lesser  skilled  technicians 
are  not  considered  equivalent  to  two  more  highly  experienced 
technicians.  Skill  is  given  a  higher  priority  than  number  in 
these  subjects.  Thus,  the  two  more  highly  skilled  technicians 
might  be  considered  adequate  to  replace  tl*B  four  lesser  skilled 
technicians,  but  not  vice  versa.  Hence,  the  skill  parameter 
appears  to  be  partially  independent  of  the  quantity  parameter, 
with  skill  being  considered  (within  limits,  of  course)  capable 
of  compensating  for  reduced  personnel  numbers. 

One  may  also  ask  how  the  engineer's  manning  concept  is 
influenced  by  manpower  requirements.  If  the  differing  person¬ 
nel  requirements  had  any  influence  or  the  engineer-subjects, 
it  should  have  been  reflected  most  immediately  in  che  number 
of  personnel  which  the  subjects  estimated  would  be  required 
to  man  their  completed  subsystem  designs.  In  session  4,  all 
subjects  were  asked  to  estimate  the  number  of  personnel  they 
considered  necessary  to  operate  their  subsystems.  They  were 
asked  to  make  the  same  estimate  also  at  the  conclusion  of  the 
study.  The  table  below  indicates  the  manning  estimates 
provided. 


HS/L#  Group  _ LS/Hf  Group 


Number  of  Personnel 

Number  of  Personnel 

Original 

Final 

Original 

Final 

Subject  Manning 

Manning 

Subject  Manning 

Manning 

1  7 

7 

1  12 

12 

2  3 

3 

2  ? 

4 

3  8 

8 

3  9 

9 

Group  Mean  6.0 

6.  C 

Group  Mean  8.  0 

8.  3 

All  subjects  in  the  HS/L#  group  had  lower  manning  estimates 
than  those  of  the  LS/H#  group,  indicative  that  these  require¬ 
ments  did  have  some  effect  on  their  estimates  of  the  manning 
required.  Unfortunately,  the  number  subjects  in  this  study 
is  too  b mall  to  make  any  meaningful  statistical  tests  of 
significance. 

Also,  with  the  exception  of  one  subject  (who  has  responding  to 
the  "buddy*1  requirement  for  safety  and  hence  added  one  man  to 
his  original  estimate  as  an  afterthought),  estimates  were  re¬ 
markably  consistent  from  session  4  to  session  10.  This  suggests 
two  things: 
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(a)  Estimates  of  manning  are  developed  quite  early  and  are 
apparently  not  influenced  by  the  addition  of  equipment  and 
personnel  information. 

(b)  Manning  estimates  are  developed  by  the  engineer  himself,  even 
though  he  may  not  verbalise  these  formally  until  later  in  design. 

Although  subjects  were  noi  formally  asked  for  manning  estimates 
until  the  fourth  session,  their  comments  in  the  first  two  test  sessions 
showed  that  subjects  had  at  least  a  rough  concept  of  the  number  of  per¬ 
sonnel  and  the  skill  level  needed  to  operate  their  subsystems.  With 
regard  to  skill  level,  all  subjects  felt  that  a  subsystem  with  potential 
hazards  in  it  required  highly  skilled  personnel.  Although  it  was  diffi¬ 
cult  for  them  to  understand  the  terms  in  which  the  Air  Force  skill  level 
designations  are  phrased,  subjects  were  acutely  aware  of  the  signifi¬ 
cance  of  skill  for  the  operation  of  their  subsystems. 

One  would  hope  that  the  manning  estimates  would  be  influenced  by 
the  QQPRI  information  provided  in  session  6.b.  The  following  estimates 
were  provided  as  part  of  the  PRD  input  for  that  session:  HS/L#  group: 

9;  LS/H#  group:  12. 

Note  that  this  input  caused  no  change  in  the  original  manning  estimates 
developed  by  engineers ,  suggesting  two  things: 

(a)  Manning  estimates  provided  downstream  in  design  have  no  effect 
on  the  engineer's  manning  concept  developed  earlier. 

(b)  The  design  engineer  is  reluctant  to  modify  his  original  manning 
concept. 

Presumably  the  engineer's  manning  concept  should  be  related  to  the 
nature  of  his  subsystem  design.  This  can  be  investigated  by  comparing 
the  manning  estimates  against  the  type  of  subsystem  design  developed. 

The  subsystem  designs  can  be  described  in  terms  of  the  following  cate¬ 
gories:  remote-manual,  semiautomated  and  completely  automated, 
representing  an  increasing  order  of  automation.  Logically,  the  more 
automated  the  design,  the  fewer  operating  personnel  should  be  required. 

Four  designs  were  classified  (by  the  designers  themselves)  as  r*. '"'ote - 
manual,  one  as  semiautomated,  and  one  as  automated.  The  manning 
involved  is  described  below: 
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Re  mote-Manual 

Semiautoma  ted 

Automated 

Subject 

Manning 

Subject 

Manning 

Subject 

Manning 

S** 

17 

J  + 

3 

H* 

9 

K* 

7 

N** 

3 

D* 

8 

Mean 

7.  5 

*  -  HS/.L#  Subject 
**  -  LS/H#  Subject 

As  in  the  previous  studies,  the  present  engmee r- subjects  designed  on 
the  basis  of  very  strongly  felt  experiential  stereotypes.  For  example, 
one  subject  "did  not  believe"  in  manual  systems,  while  another  believed 
just  as  strongly  that  automated  systems  were  "no  good.  "  Hence,  the 
choice  of  a  design  concept  was  probably  not  markedly  influenced  by  the 
personnel  requirements  levied  on  the  individual  engineer. 

It  is  even  more  disturbing  to  find  there  is  little  or  no  correlation  be¬ 
tween  the  type  of  design  proposed  and  the  manning  indicated  by  engineers 
for  theoe  designs.  The  one  completely  automated  design  required  more 
personnel  than  the  mean  of  the  group  of  four  engineers  who  designed 
manual  systems.  On  the  other  hand,  the  semiautomated  design  required 
substantially  fewer  personnel  than  either  the  completely  automated  or 
manual  subsystems. 

This  suggests  very  strongly  that  design  engineers  have  a  very  inapprop¬ 
riate  concept  of  the  manpower  required  to  operate  their  systems.  From 
this,  one  can  deduce  that  the  services  of  professionally  qualified  man¬ 
power  estimators  are  required  because  one  cannot  rely  on  the  engineer 
to  develop  a  manning  concept  appropriate  to  his  subsystem  design. 

Particular  attention  should  be  drawn  to  the  fact  that  all  engineers  had 
great  difficulty  in  understanding  the  meaning  of  skill  levels  phrased  m 
the  Air  Force's  "3.  5,  7-ievel"  terminology.  Although  such  designations 
are  undoubtedly  useful  for  Air  Force  administrative  purposes,  they  have 
no  meaning  for  design  engineers.  At  the  present  time,  little  is  known 
about  the  parameters  involved  in  the  skill  level  concept,  particularly 
those  aspects  which  relate  to  equipment  design. 


2.  Do  Personnel  Resources  Data  Inputs  Have  a  Significant  Effect  or. 


Quantitative  Analyses 

The  basic  measure  here  is  the  comparison  between  the  outputs  ot  the 
experimental  and  those  of  the  control  subjects  (who  did  not  receive  the 


PRD  input  during  the  secsion  in  which  they  provided  the  output). 

Control  subjects  varied  from  session  to  session;  hence,  it  is  impossible 
to  compare  the  results  of  one  session  with  those  of  another,  or  to  com¬ 
pare  overall  subsystem  designs  for  control  subjects.  Results  arc  avail¬ 
able  on  a  session-by-session  basis  only. 

Session  1 

Inputs;  Statement  of  work  and  personnel  function 

flow  diagrams. 

Design  output;  Number  of  personnel -related  functions 

specified  in  schematics. 

Experimental  Mean  5.  3 

Subjects; 

Control  Mean  5.  5 

Sessions  2-3 
Inputs: 


Design  Output; 

Experimental 
Subjects; 

Control  Subjects 
Session  4 

Inputs;  Additional  equipment  information  and  a 

prelin  inary  operations  task  analysis. 

Design  Output:  Numler  of  control -display  hardware 

items  no  ted. 

Experimental  Mean  173.7 

Subjects: 

Control  Subjects  Mean  50.  0 


(2)  Partially  completed  Requirements 
Allocation  Sheets  (RAS). 

(3)  Supplemental  equipment  information 
and  control /display  memorandum. 

Number  of  personnel  -  related  equipment 
items  specified. 

Mean  75.  5 


Mean  39.  0 
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Session  5 


Inputs: 

Design  Output: 

Experimental 

Subjects: 

Control  Subjects: 

Session  7 
Inputs: 

Design  Output: 

Experimental 

Subjects: 

Control  Subjects: 


Requirements  Allocation  Sheets  dealing 
with  Preventive  Maintenance. 

Number  of  maintenance/test  equipment 
items  noted. 

Mean  2.  3 

Mean  1.5 


Complete  QQPRI 

Number  of  operating  problems  anticipated. 
Mean  8. 5 

Mean  13.5 


Again,  it  must  be  emphasized  that  with  the  small  number  of  subjects 
available  (at  each  session  four  experimental  and  two  control  subjects) 
the  results  can  be  indicative  only.  With  this  qualification  it  would 
appear  as  if  certain  PRD  inputs  did  have  major  effects  (sessions  2,  3, 
and  4).  Certainly,  the  number  of  personnel  related  equipment  and 
control -di  splay  items  noted  were  substantially  greater  for  experimental 
than  for  control  subjects.  The  number  of  maintenance/test  equipment 
items  produced  by  all  subjects  in  session  5  and  the  number  of  operating 
problems  anticipated  in  session  7  were  too  small  to  draw  any  conclusions 
relative  to  the  hypothesis. 

If  one  associates  the  type  of  PRD  input  with  the  individual  test  sessions, 
it  is  possible  to  develop  an  explanation  for  some  of  £he  conflicts  in  these 
results.  Sessions  2-4,  those  with  the  most  significant  differences  between 
experimental  and  control  subjects,  presented  PRD  inputs  which  engineers 
utilize  most  readily.  These  inputs  are  task  performance  requirement  b, 
personnel/equipment  analyses  (e.  g.  ,  control-display  memorandum)  and 
preliminary  task  analysis. 

In  session  7,  which  showed  a  slight  reversal  between  experimental 
and  control  subjects,  the  experimental  subjects  had  received  the  QQPRI 
which  listed  many  of  the  potential  operating  problems  which  the  designers 
had  been  asked  to  anticipate.  It  is  possible  that  the  engineers  in  the 
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experimental  group  felt  that  they  need  only  add  certain  problems  to  the 
list  already  provided  in  the  QQPRI.  Since  only  these  additional  operat¬ 
ing  problems  could  be  counted  for  the  experimental-control  group  com¬ 
parison,  the  number  of  these  problems  would  be  less  than  that  produced 
by  the  control  group. 

One  may  ask  how,  in  view  of  the  engineer's  indifference  to  PRD  inputs, 
some  of  these  inputs  could  exercise  an  influence  on  design  outputs.  What¬ 
ever  other  specific  value  these  inputs  possessed,  they  were  valuable  from 
the  standpoint  of  "prodding"  the  engineer  to  consider  certain  aspects  which 
he  had  overlooked.  For  example,  the  memorandum  of  control-display 
requirements  may  not  have  caused  the  designer  to  buy  the  particular  con¬ 
figuration  described  in  the  memorandum,  but  it  caused  him  to  think  about 
the  need  for  controls  and  displays  in  general. 

Likewise,  when  maintainability  inputs  were  presented  to  subjects  in 
session  5,  some  of  the  engineers  reported  that  they  had  completely  for¬ 
gotten  up  to  that  point  about  subsystem  maintainability.  The  new  input 
then  required  them  to  modify  their  design  somewhat.  Thus,  even  when 
it  appears  as  if  a  particular  PRD  input  has  missed  its  mark  because  it 
does  not  produce  an  immediate  effect  in  terms  of  the  design  change  for 
which  it  was  developed,  it  serves  a  useful  purpose  in  reminding  the 
engineer  of  factors  he  might  otherwise  have  ignored. 

Qualitative  Analysis 


Results  of  the  debriefing  episodes  at  the  conclusion  of  each  test  session 
produced  varying  responses  to  the  question  of  PRD  utility. 

In  the  first  two  sessions,  all  subjects  indicated  that  the  PRD  provided 
would  not  be  particularly  useful  at  this  stage  of  design,  but  that  perhaps 
it  would  be  of  more  value  later  in  the  design  process  (later  on  being  re¬ 
lated  to  the  creation  of  operating  procedures,  etc.).  In  this  connection, 
note  that  a  PRD  input  was  seen  as  useful  when  it  could  be  immediately 
(or  eventually)  tied  to  some  concrete  system  design  output,  such  as  an 
operating  procedure. 

In  the  third  session,  subject  opinion  was  split  as  to  the  value  of  PRD. 
Half  the  subjects  indicated  that  they  still  saw  no  need  for  PRD,  including 
what  was  previously  available.  The  other  half  indicated  that  they  felt 
some  indication  of  the  type  and  quantity  of  people  as  a  definite  necessity 
at  this  design  stage. 

•* 

In  later  sessions,  the  utility  of  PRD  inputs  did  not  show  significant 
improvement,  particularly  because  of  inappropriate  timing.  That  is, 
decisions  as  to  the  number  r.nd  location  of  control  panels,  for  instance, 
had  been  made  by  the  individual  designer  far  in  advance  of  the  arrival 
of  the  memorandum  describing  human  factors  recommendations  for  these 
items.  This  tendency  of  PRD  to  arrive  too  late  to  influence  engineering 
decisions  was  repeated  at  every  stage  of  design. 
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Three  of  the  six  subjects  were  consistently  more  positive  in  their 
reactions  to  PRD  inputs  than  the  remaining  three. 

An  analysis  of  subject  characteristics  (e.  g.  ,  years  of  experience, 
educational  background,  type  of  job  responsibility)  does  not  indicate 
any  particular  factor,  other  than  their  attitude,  which  differentiated 
them  from  nonreceptive  engineers.  This  suggests  that,  if  the  subject 
sample  used  in  this  study  are  representative  of  the  entire  engineering 
population,  there  are  many  more  engineers  than  had  been  suspected 
who  can  be  influenced  to  some  degree  by  personnel  resources  require¬ 
ments.  It  also  suggests  the  need  to  study  engineers  in  greater  detail 
concerning  what  can  be  termed  their  "design  style." 

3.  At  What  Stage  of  Subsystem  Development  Do  Manpower  Requirements 
and  Personnel  Resources  Data  Have  Their  Greatest  Effect  on  "Eq^  np- 
ment  Design? 

The  consensus  of  subject  opinion  with  regard  to  PRD  inputs  was  that 
they  would  have  considerably  greater  impact  if  they  were  made  available 
either  in  conjunction  with  or  soon  after  the  SOW.  Engineers  indicated 
that  specific  items  of  information,  such  as  the  number  of  personnel  the 
subsystem  should  utilize,  recommended  controls  and  displays,  etc.  , 
would  probably  have  a  greater  effect  on  equipment  design  if  they  were 
presented  as  requirements  within  the  SOW.  Throughout  the  test  program, 
subjects  reiterated  that  in  order  for  PRD  inputs  to  be  particularly  effec¬ 
tive  in  influencing  or  changing  an  already  established  or  about  to  be 
established  design  they  must  either  be  provided  early  enough  to  act  as 
one  of  the  initiators  of  the  design  concept  or  be  a  constraint  or  restric¬ 
tion  imposed  upon  the  designer. 

4.  In  What  Forms  are  PRD  Inputs  Most  Effectively  Used  by  Designers? 

With  regard  to  the  individual  PRD  inputs,  the  following  car.  be  said: 

(1)  Statement  of  work,  including  definition  of  skill  level  and  flow 
diagrams  ot  personnel  functions.  Because  these  inputs  were 
purely  informational  (i.  e.  ,  not  phrased  as  requirements),  they 
were  considered  by  engineers  as  having  no  influence  on  design. 
This  does  not  conflict  with  the  statements  made  immediately 
above.  These  inputs  would  have  been  effective  had  they  been 
phrased  as  requirements  and  included  in  the  SOW.  As  purely 
information  data,  they  were  thought  to  be  more  appropriate  to 
a  later  design  stage.  The  reason  for  this  is  that  engineers 
typically  feel  that  personnel  data  as  data  should  be  outgrowths 
of  equipment  rather  than  as  factors  influencing  that  design; 
hence,  they  considered  that  these  inputs  should  be  delayed 
until  that  design  had  been  formalized. 
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Requirements  Allocation  Sheets  with  personnel  section  completed 
and  more  detailed  diagram  of  required  personnel  functions. 
Subjects  interpreted  the  PRD  input  as  a  preliminary  operating 
procedure.  They  felt  that  "the  design  should  dictate  this  (the 
PRD  input)  rather  than  have  the  PRD  control  design.  "  Informed 
that  the  PRD  input  was  an  outgrowth  of  design  rather  than  a  con¬ 
straint  on  it,  the  engineer  proceeded  to  ignore  it. 

Control -display  memorandum.  Five  of  the  subjects  found  the 
memorandum  more  or  Jess  useful  in  that  they  interpreted  it  as 
being  directive  of  a  certain  approach  toward  controls  and  dis¬ 
plays  which  the  customer  wanted  taken.  The  sixth  subject  re¬ 
jected  the  memorandum  because  it  conflicted  with  the  design 
approach  he  had  adopted. 

Preliminary  task  analysis.  Subjects  all  concurred  that  the  task 
anaiysia  had  some  value.  Half  the  subjects  indicated  that  they 
would  not  expect  to  receive  this  kind  of  information  during  de¬ 
sign,  while  the  others  indicated  that  they  would  have  to  develop 
this  kind  of  information  themselves  in  the  course  of  design. 

When  questioned  as  to  the  elements  of  the  task  analysis  which 
were  particularly  useful,  half  the  subjects  indicated  that  the 
simple  task  listing  was  the  most  useful;  the  other  indicated  that 
the  performance  requirements  section,  e.g.  ,  specification  of 
task  complexity,  communications  needed,  etc.  ,  was  the  most 
uaeful  element. 

Maintenance  analysis  (included  on  Requirements  Allocation 
Sheet): — This  includes  preventive  maintenance  functions  with 
personnel  section  of  the  Requirements  Allocation  Sheet  (RAS) 
filled  out,  supplemented  by  a  maintainability  checklist.  Sub¬ 
ject  reactions  indicated  that  four  of  the  subjects  regarded  the 
information  provided  as  useful  and  having  an  impact  on  the 
assigned  task.  They  found  the  data  under  the  task  heading  or 
the  RAS  to  be  m  ,st  usef’d.  The  other  two  subjects  were  not 
impressed  by  nor  did  they  find  the  RAS  useful. 

Three  of  the  subjects  regarded  the  checklist  provided  as  an 
extremely  useful  tool.  The  other  three,  however,  were  not 
impressed  and  in  one  case  even  opposed  the  use  of  the  checklist, 
i.  e.  ,  it  was  something  a  "checker"  would  use  to  check  a  design. 
Those  opposing  the  checklist  indicated  that  all  the  elements 
mentioned  in  the  checklist  constituted  an  integral  part  of  "good 
destgn,:  or  good  standard  practice,  and  that  while  the  designer 
may  not  outwardly  mention  these  things,  they  are  present  in 
the  "back  of  his  mind'1  and  the  important  things  would  get  taken 
care  of. 
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(6) 


Time  line  analyses.  There  was  one  each  for  operations  and 
maintenance  functions,  and  a  Preliminary  QQPRI  (see  Glossary) 
described  the  qualifications  and  number  of  personnel  required 
in  the  system.  Subjects  did  not  view  the  time-line  analysis  as 
particularly  helpful,  indicating  that  its  informational  content 
merely  confirmed  their  own  conception  of  time  sequences  in 
their  system.  With  regard  to  the  QQPRI,  all  but  one  of  the  sub¬ 
jects  disagreed  with  the  number  of  personnel  predicted.  The 
only  subject  agreeing  with  the  QQPRI  prediction  did  so  because 
of  the  chance  coincidence  of  his  prediction  with  that  of  the  QQPRI. 
Subjects  refused  to  modify  their  predictions  of  the  crew  sizes 
they  had  selected. 

(7)  Full  Scale  QQPRI.  The  existence  of  the  QQPRI  had  no  significant 
effect  on  subject  performance  and  only  one  subject  indicated  that 
it  was  useful.  Questioned  as  to  the  effect  of  timing,  subject  opin¬ 
ion  was  evenly  divided  between  those  who  felt  it  was  impossible 
to  develop  this  level  of  detail  any  earlier  and  those  who  felt  that 
this  type  of  information  would  be  most  useful  at  the  inception  of 
design. 


It  is  obvious  from  these  subject  responses  that  no  simple  yes  or  no 
answer  can  be  provided  to  the  question  of  utility.  Certain  inputs  do  have 
value:  those  which  describe  the  operations  of  the  system,  such  as  task 
information;  and  those  which  are  interpreted  as  representing  the  custom¬ 
er's  wishes  (e.g.  ,  control -display  memorandum),  thus  imposing  a  de¬ 
sign  requirement.  The  directness  of  the  relationship  of  the  input  to 
equipment  features  is  important  also:  those  inputs,  such  as  training  re¬ 
quirements,  position  descriptions,  etc.  ,  which  have  only  a  peripheral 
relationship  to  equipment  functioning  are  considered  of  much  less  im¬ 
portance  than  inputs  such  as  lists  of  tasks. 

Additional  evidence  is  available  from  rankings  supplied  by  subjects  in 
Items  9-2,  9-5,  and  10-3  concerning  the  particular  PRD  items  which  are 
the  most  useful  and  have  greatest  effect  on  design. 

Item  9-2.  Subjects  were  asked  to  rank  the  importance  of  all  inputs 
provided  to  them  during  the  study.  The  mean  rank  assigned  to  each 
individual  input  is  shown  in  Table  X.  The  disparity  in  responses  noted 
previously  is  reflected  in  the  subjects'  lack  of  consistency,  with  Kendall's 
W  statistic  (.  38)  failing  to  be  significant  at  the  .05  level.  However,  the 
mean  rankings  are  consistent  with  other  subject  mean  responses  during 
the  test  sessions. 

As  would  be  expected,  the  SOW  and  the  additional  equipment  informa¬ 
tion  provided  during  the  sessions  were  considered  most  important.  Of 
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TABLE  X 


RANKING  OF  THE  IMPORTANCE  OF  INPUTS 
PROVIDED  DURING  THE  STUDY 


Mean  Ranking 


Item 


1 

2 

3 

4 

5 

6-7  (tie) 

8 

9 

10 

11 

12 

13 

14 


Statement  of  Work 

Additional  equipment  information 

Performance  requirement  on  RAS  i 

I 

Control -display  memorandum 
Description  of  tasks 
List  of  personnel  tasks 
Task  durations 

Functional  flow  diagrams  for  personnel 
functions 

Number  of  personnel  available 

Difficulty  index 

Kinds  of  personnel  available 

Probability  of  successful  task 
completion 

Time-line  analysis 

Training  requirements 


the  PRD  inputs,  the  most  important  are  those  which  are  equipmenr- 
oriented  in  terms  of  the  operations  needed  to  be  performed.  Task 
information  which  cannot  be  readily  related  to  equipment  operations  is 
considered  of  little  importance. 

Upon  completion  of  the  ranking  task,  subjects  were  questioned  as  to 
the  utility  of  the  info’-’-’-ation  contained  in  the  input,  the  impact  of  that 
information  upon  his  design  (if  any),  and  the  sequencing  ot  the  input. 

Item  5-8.  Subject's  rankings  of  the  relative  value  to  be  placed  upon 
items  which  might  appear  in  a  statement  of  work  (SOW)  are  eummarited 
in  Table  XI.  Those  items  were  presented  to  subjects  as  they  might 
appear  in  a  SOW  for  the  design  of  a  PTPS  to  be  manned  by  Air  Force 
technicians  about  whom  the  design  engineer  knew  nothing. 

As  before,  those  items  which  are  restrictive  are  given  higher  priority 
than  those  which  are  essentially  informational  in  nature.  Cost  and  physi¬ 
cal  equipment  parameters  rank  higher  than  any  behavioral  parameters. 
However,  the  sequence  of  task  operations  and  the  maximum  number  of 
personnel  permitted  in  the  crew  take  fourth  place.  Skill  and  difficulty 
level  descriptions,  human  error  probabilities  and  training  details  are 
considered  relatively  of  little  value.  Kendall's  Wr  statistic  indicates  that 
subjects  are  fairly  consistent  in  their  responses  to  this  item.  W  =  .61, 
which  is  significant  at  the  .  05  level. 

Item  10-3.  In  Item  10-3,  subjects  were  asked  to  rank  the  items  of 
information  they  might  want  to  know  in  order  to  develop  an  appropriate 
design  for  a  PTPS  system  to  be  operated  by  only  two  men.  The  under¬ 
lying  hypothesis  was  that  the  extreme  restrictions  on  the  number  of  per¬ 
sonnel  to  operate  the  system  might  cause  subjects  to  change  the  order 
of  priority  of  the  various  informational  parameters  available  to  them, 
in  other  words,  to  emphasize  more  information  items  relative  to  per¬ 
sonnel.  The  results  of  the  ranking  is  shown  in  Table  XII.  Subject 
responses  are  consistent,  as  measured  by  Kendall's  W,  at  the  .  05  level 
(.51). 

Despite  the  severity  of  the  personnel  requirement,  apparently  the 
engineer  still  structures  his  design  analysis  first  in  terms  of  the  physical 
parameters  describing  tb.2  system.  Thus,  the  first  four  items  ranked  all 
relate  to  the  physical  parameters  of  the  system  configuration.  It  is  only 
after  this  that  parameters  which  we  would  consider  to  be  per  sonnel  -  re!  ated 
(e.  g.  .  sequence  of  task  operations ,  concurrent  task,  skill  level,  etc.) 
are  considered.  As  before,  training,  human  error  probabilities,  and 
personnel  availability  are  considered  of  relatively  little  importance 
because  of  their  more  abstract  nature. 


t 
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Coat  restrictions,  if  any 

Customer's  philosophy  with  regard  to  sub¬ 
system  automation 

Physical  configuration  of  the  site  on  which 
the  FTPS  is  to  be  located 

The  maximum  number  of  men  you  will  be 
permitted  to  have  in  each  crew 

Sequence  of  task  operations 

Lists  of  tasks  to  be  performed  by  each 
crew  member 

Criticality  of  each  task  to  be  performed, 
in  terms  of  consequences  to  system 
performance  and  safety 

Identification  of  which  tasks  must  be 
performed  concurrently 

Number  of  personnel  required  to  perform 
each  task 

Description  of  the  experience  background 
which  crew  members  must  have 

Air  Force  skill  level  designators  of  system 
personnel 

Difficulty  associated  with  each  task 

Probability  of  human  error  in  performing 
tasks 

Details  of  the  training  which  will  be  pro¬ 
vided  to  the  Air  Force  technicians 

Availability  of  personnel  within  the  Air 
Force  to  become  FTPS  operators 


TABLE  XII 


ITEMS  OF  INFORMATION  OF  IMPORTANCE 
IN  THE  DESIGN  OF  THE  TWO -MAN  PTPS 


Mean  Rank 

item 

1 

Manner  in  which  fuel  will  be  transported  to 
the  RSV 

2 

Type  of  fuel  to  be  transferred 

3 

Physical  configuration  of  the  site  on  which 
the  PTPS  is  to  be  located 

4 

Required  performance  reliability  of  the 
system 

5 

Sequence  of  task  operations 

6 

Identification  of  which  tasks  must  be  per¬ 
formed  concurrently 

7 

The  speed  with  which  each  individual  task 
must  be  performed 

8 

Latest  information  about  process  control 
equipment 

9 

Air  Force  skill  level  designation  of  pro¬ 
spective  personnel 

10 

Education  background  to  be  required  of 
prospective  personnel 

LI 

The  number  of  displays  which  can  be 
accurately  monitored  by  one  man  at 
the  same  time 

12 

Criticality  to  system  operation  of  individ¬ 
ual  tasks 

13 

Analysis  of  which  tasks  should b.  performed 
by  personnel 

14 

Electrical  power  requirements 
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TABLE  XII  (concluded) 


ITEMS  Of  INFORMATION  OF  IMPORTANCE 
IN  THE  DESIGN  OF  THE  TWO -MAN  PTPS 


Mean  Rank 


Item 


15 


Analysis  of  the  types  of  human  errors  which 
might  occur  in  operation 


16 


Probability  of  human  error  in  performing 
individual  tasks 


17 

18 

19 

20 


Description  of  the  training  to  be  given  to 
personnel 

Availability  of  personnel  within  the  Air  Force 
to  become  PTPS  operators 

Speed  with  which  personnel  in  protective 
clothing  can  react 

Average  reach  distance  of  Air  Force 
personnel 


5.  What  is  the  Design  Engineer's  Concept  of  Human  Factors  in  Systems 

design  and  His  Attitude  Toward  ftRD  Inputs^  ~ 

Little  more  can  be  added  to  what  has  been  described  previously.  The 
attitudinal  problem  as  it  affects  the  use  of  PRD  inputs  is  probably  the 
moat  severe  one  of  the  complex  of  factors  which  militate  against  the 
engineer's  use  of  those  inputs. 

The  acceptability  of  an  input  is  determined  to  a  great  extent  by  its 
source.  One  can  think  of  an  input  as  emanating  from  a  higher  level 
(e.  g.  ,  customer,  company  management),  from  a  level  parallel  to  the 
designer  (e.g.  ,  an  engineering  group  recognized  by  the  engineer  as 
having  a  technical  capability  equal  to  his  own),  or  from  a  lower  levc1 
(e.  g.  ,  from  a  group  which  is  not  part  of  engineering  or  which  does  not 
have  status  equal  to  the  designer's. 

An  input  stemming  from  a  higher  level  is  ordinarily  accepted  as 
"gospel";  undoubtedly,  this  is  related  to  the  engineer's  perception  of 
the  input  as  imposing  a  design  requirement.  He  may  consider  the  input 
as  idiotic,  but  he  will  comply,  provided  he  has  no  other  recourse. 

Lateral  inputs  (e.  g.  ,  from  a  level  parallel  to  that  of  the  engineer's)  are 
reviewed  and  accepted  if  they  fit  into  the  designer's  concept  or  are  con¬ 
sidered  technically  correct  (i.  e.  ,  cannot  be  successfully  attacked). 

Inputs  from  a  lower  level  (a  human  factors  group  is  often  in  this  attitud¬ 
inal  category)  are  usually  rejected  or  accepted  only  after  much  resistance. 

The  engineer  is  very  critical  of  anything  which  he  considers  to  be 
technically  incorrect.  Vague  inputs  (i.e.  ,  phrased  in  generalities) 
offend  his  sense  of  precision  and  concreteness.  The  engineer  requires 
that  the  input  be  specific,  spelled  out  in  detail,  as  well  as  being  prac¬ 
tical;  consequently,  the  personnel  specialist  may  have  to  demonstrate 
the  practicality  of  his  recommendations.  Finally,  the  input  has  to 
tell  the  engineer  something  he  has  not  thought  of  before  or  something 
he  has  not  fully  thought  out  until  now.  All  of  this  can  be  summed  up  by 
saying  that  if  the  personnel  specialist  is  accepted  by  the  engineer  as  an 
equal  (i.  e.  ,  as  technically  competent),  what  he  has  to  say  about  the 
engineer's  design  will  be  accepted  at  face  value. 

6.  How  Does  the  Manner  in  Which  the  Engineer  Designs  Affect  the 
Utilization  ot  PH.D  Inputs ? 

The  most  surprising  finding  relative  to  the  manner  in  which  the  engineer 
designs  was  the  speed  with  which  he  proceeded  to  definitive  his  subsystem 
configuration. 
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It  has  been  assumed  that  the  development  of  equipment  details  would 
be  preceded  by  the  following  analytic  stages: 

(1)  Determination  of  system/equipment  functions 

(2)  The  allocation  of  functions  between  equipment  and  personnel 

(3)  The  specification  of  equipment  design  requirements  (as  distinct 
from  system  requirements) 

(4)  The  interrelationship  between  equipment  functions 

(5)  The  specification  of  equipment  characteristics  to  satisfy  equip¬ 
ment  requirements  and  functions 

Sessions  1  through  4  were  delibt. ately  devised  to  permit  the  engineer 
to  reveal  these  analytic  processes  overfly.  The  experimental  approach 
was  specifically  modeled  on  the  system  analytic  steps  listed  above,  and 
explicitly  called  for  the  subjects  to  make  analytical  decisions  in  accord¬ 
ance  with  this  process.  For  example,  the  first  session  required  the 
subject  to  detail  system  functions  and  subfunctions;  the  second  session 
asked  him  to  detail  equipment  functions  and  subfunctions;  and  the  third 
session  asked  him  to  specify  equipments  needed  to  implement  these 
functions,  etc. 

To  the  investigator's  surprise,  all  subjects  in  the  first  session  re¬ 
sponded  by  producing  a  detailed  schematic  diagram  which  included  the 
following  features: 

(1)  Explicit  equipments  needed,  e.  g.  ,  heat  exchanger 

(2)  Piping  lines  between  equipments  and  even  geograpnical  (site) 
arrangements 

(3)  Valving  required  to  operate  the  equipment 

(4)  Determination  of  which  valves  would  be  remotely  and  which 
manually  operated 

(5)  Equipment  tolerances 

(6)  Some  indication  of  crew  size  and  composition 

Figures  12  and  1  3  in  Appendix  III  show  tne  level  of  detail  produced 
in  the  first  session. 

In  the  very  first  session,  subjects  had  developed  a  complete  design 
concept;  and  subsequent  sessions  merely  enabled  them  to  refine  the 
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concept,  but  only  in  a  very  molecular  manner  (e.g.  ,  addition/deletion 
of  individual  valves,  etc.).  Under  these  circumstances,  almost  all  of 
the  PRD  inputs  provided  were  late,  in  the  sense  that  the  basic  design 
decisions  to  which  they  had  relevance  had  already  been  determined. 

Once  such  decisions  are  made  by  the  engineer,  they  are  almost  impos¬ 
sible  to  change,  as  seen  by  the  response  of  the  subjects  to  the  changed 
personnel  requirements  in  session  8. 

Under  these  circumstances,  if  PRD  analyses  and  inputs  are  to  have 
any  effect  on  design,  they  must  be  available  at  the  very  start  of  design. 
This  may  appear  to  be  at  variance  with  the  comments  of  some  subjects, 
when  they  indicated  that  such  PRD  inputs  were  too  early,  or  should  be 
provided  only  later,  or  would  be  of  greater  value  later  in  design.  The 
contradiction  is  explained  by  tne  fact,  pointed  out  previously,  that 
engineers  typically  think  of  personnel  inputs  as  relating  to  molecular, 
"knobs  and  dials"  characteristics  of  the  equipment  which  are  handled 
later  on  in  design. 

Evidence  with  regard  to  the  criteria  which  the  engineer  applies  to 
his  designs  is  presented  in  Table  XIII.  In  Item  9-1,  engineers  were 
asked  to  rank  the  relative  importance  of  various  parameters  to  their 
design  and  the  degree  to  which  they  should  influence  the  designer.  The 
same  test  item  had  been  administered  to  the  two  groups  of  engineers 
tested  in  the  previous  studies  (BR  -  Bunker-Ramo,  DAC  -  Douglas  Air¬ 
craft).  It  was  administered  to  the  present  subjects  to  determine  whether 
the  present  engineer -subjects  approached  design  with  the  same  attitudes 
as  previous  subjects.  To  the  extent  that  they  did,  it  would  permit  one  to 
combine  the  findings  of  the  previous  studies  with  those  of  the  present 
one.  In  addition,  it  was  of  interest  to  determine  the  relative  priority 
assigned  to  the  various  considerations  that  may  enter  into  the  designer's 
analysis  of  his  design  problem. 

Responses  of  the  six  subjects  were  fairly  consistent  when  measured 
with  Kendall's  W,  being  significant  (.  38)  at  the  .  1)5  level.  The  Spear¬ 
man  rank  order  correlation  coefficient  was  applied  to  determine  the 
consist»ncy  of  Marquardt  (TMC)  subjects  with  BRC  and  DAC  subjects. 

The  correlations  between  TMC  and  BR,  and  between  TMC  and  DAC 
subjects  are  significant  at  the  .  05  level  or  better.  As  with  all  other 
indices  of  design  style  noted  previously,  the  present  subjects  are  con¬ 
cerned  primarily  with  physical  parameters,  equipment  characteristics, 
cost  and  reliability.  The  importance  of  personnel  factors  is  relatively 
low  on  the  scale. 

It  seems  reasonable  to  assume,  therefore,  that  the  present  subjects 
are  highly  representative  of  engineering  population  as  a  whole. 
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TABLE  XIII 


RELATIVE  IMPORTANCE  OF  DESIGN  PARAMETERS 


Rank  ) 

j 

TMC 

DAC 

B-R 

Design  Parameters 

I 

4 

1 

The  physical  characteristics  of  the 
environment  (e,  g.  ,  te  nperature  and 
vibration)  which  the  equipment  must 
tolerate. 

2 

5 

2 

The  reliability  required  of  the  equip¬ 
ment  (e.g,,  1  80  hour s  MTBF). 

3 

2 

3 

Characteristics  of  the  equipment  (e.g.  , 
type  of  component,  its  operating  mode, 
and  the  way  in  which  internal  compon¬ 
ents  must  be  mounted). 

4 

6 

9 

The  relative  cost  of  components  tc  be 
selected  for  use  in  the  equipment. 

5 

3 

5 

The  complexity  of  equipment  operat¬ 
ing  procedures. 

6 

1 

4 

The  effect  of  equipment  characteristics 
on  the  ease  with  which  personnel 
operate  and  maintain  the  equipment. 

7 

9 

"f 

) 

The  accessibility  of  internal  equipment 
components  to  maintenance  personnel. 

o 

7 

6 

The  ease  with  which  equipment  can  be 
man  ufactured. 

9 

8 

4 

The  manner  m  which  the  equipment 
should  be  calibrated  and  maintained. 

Rank 

Rank 

correlation  between  TMC  and 
correlation  between  TMC  and 

DAC  groups  .  4o.  p  .08 

t>K  groups  .  9  7  .  p  .08 

Rank  correlation  between  DAC  and  BR  groups 


7.  How  Available  is  Information  as  a  Whole  to  the  Engineer  During  Design? 

In  general,  engineers  receive  less  information  than  they  would  prefer 
to  have.  On  the  other  hand,  their  attitude  toward  that  information  is 
highly  significant. 

Depending  on  the  engineer's  design  style,  he  either  welcomes  as  much 
information  as  possible  as  early  as  possible,  or  views  information  as 
potentially  constraining  his  freedom  to  design  creatively.  The  former 
would  be  willing  to  accept  PRD  inputs  even  if  they  did  not  use  them.  The 
latter  would  vehemently  refuse  even  to  accept  such  inputs.  Ch.e  subject 
had  to  be  replaced  after  the  initial  session,  because  he  considered  that 
the  personnel  inpucs  for  session  2  were  so  detailed  as  to  demean  him 
(e.g.  ,  "an  experienced  designer  doesn't  need  all  th.s  (word  deleted)  in¬ 
formation;  if  you  have  to  tell  an  engineer  all  these  things,  you  may  as 
well  get  someone  off  the  street,"  etc. 

B.  CONCLUSIONS 

The  major  conclusions  one  can  derive  from  this  study  are  summar¬ 
ized  below; 

(1)  Manpower  requirements  and  personnel  resources  data  inputs  do 
have  an  influence  on  the  equipment  configuration,  but  this  influ¬ 
ence  is  attenuated  by  a  complex  of  factors  such  as  the  engineer's 
indifference  to  and  inability  to  interpret  human  factors  consid¬ 
erations  meaningfully,  and  more  importantly,  by  the  inadequa?. 
timing  cf  PRD  inputs. 

(2)  The  potential  influence  of  personnel  requirements  and  PRD  inputs 
on  the  equipment  contigurati on  is  much  greater  than  is  presently 
achieved.  PRD  inputs  would  exercise  much  greater  effect  if 
they  were 

(a)  Phrased  as  specific  design  requirements  and  constraints 
and  included  in  the  SOW ; 

( b )  Phrased  in  concrete  design- relevant  terms. 

(3)  The  manner  in  which  the  engineer  designs  has  a  significant 
effect  upon  his  reaction  to  personnel  requirements  and  his  use 
of  PRD  inputs,  hence  on  their  influence  on  the  subsystem  con¬ 
figuration.  The  engineer's  design  concept  Is  so  quickly  developed 
on  the  basis  of  experiential  stereotypes  (design  style)  that 
traditional  timing  of  MR  and  PRD  inputs  iag  that  concept.  The 
engineer  resists  any  change  to  his  initial  design  concept  as  a 
restriction  on  his  treedom  o  design  creatively. 
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(4)  The  importance  of  supplying  meaningful  manpower  information 
as  design  requirements  in  the  SOW  and  subsequent  QQPRI 
analyses  by  trained  Human  Factors  personnel  is  highlighted  by 
the  fact  that  the  engineer's  manning  concept  does  for  his  own 
design  not  appear  to  correspond  to  the  needs  of  his  subsystem 
designs. 

(5)  The  results  of  this  study  are  in  accordance  with  those  of  pre¬ 
vious  design  engineering  studies.  This  increases  the  confidence 
one  can  feel  in  the  conclusions  derived. 
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SECTION  IV 


RECOMMENDATIONS 


The  fact  is  that  the  engineer,  relying  heavily  on  his  past  experience, 
develops  his  hardware  configuration  soon  after  he  receives  his  Request 
for  Proposal  (RFP)  and  design  statement  of  work  (SOW).  This  means 
thaf  almost  all  manpower  requirements  and  personnel  resources  data 
inputs  provided  after  this  point  in  time  will  lag  that  hardware  configura¬ 
tion  and  the  decisions  which  entered  into  the  design  concept.  Presently, 
these  inputs  are  supplied  by  Human  Factors  personnel  progressively 
during  the  contractor's  design  of  the  system.  If  what  has  been  found  in 
this  study  can  be  relied  on,  this  incremental  development  of  PRD  has 
only  marginal  utility  to  the  engineer  and  little  impact  upon  his  design. 

There  is  independent  evidence  for  the  engineer's  extremely  rapid 
creation  of  the  design  concept  and  his  excessive  reliance  on  experience 
as  a  substitute  for  systematic  analysis  of  the  design  problem.  Tessmer 
(1967)  analyzed  a  number  of  actual  system  development  case  histories 
to  determine  the  criteria  used  for  systems  tradeoffs.  He  found  that  "in 
practice,  most  tradeoff  areas  are  identified  and  tentative  decisions  made 
during  preproposal  and  proposal  efforts  (emphasis  supplied  by  the 
authors"]^  These  decisions  are  solidified  or  modified  within  the  first 
fe  w  I'O.iLhs  after  contract  award.  It  is  remarkable  that  so  many  trade¬ 
offs  are  typically  resolved  in  so  short  a  time.  A  key  factor  is  engineer¬ 
ing  experience.  .  .  There  is  an  aspect  associated  with  extensive  exper¬ 
ience  which  should  be  recognized.  The  possibility  exists  for  excessive 
"design  by  decision"  with  too  few  detailed  studies  of  areas  which  should, 
in  fact,  be  thoroughly  investigated.  Sometimes  the  correct  decisions 
are  made,  but  this  seems  attributable  to  good  luck,  .as  well  as  exper¬ 
ience"  (p.  3-3). 

It  would  seem  then  that  manpower  requirements  and  PRD  must  be 
available  to  the  design  engineer  at  the  time  the  RFP  and  design  SOW  are 
supplied  to  him.  PRD  inputs  should  be  included  in  the  RFP  and  SOW  as 
design  requirements. 

In  order  to  accomplish  this,  however,  certain  analyses  must  be  per¬ 
formed,  either  by  the  Air  Force  or  under  contract  to  it,  which  will 
permit  the  specification  of  the  necessary  personnel  inputs  as  timely 
design  requirements. 

Until  now,  these  analyses  have  (with  only  a  few  exceptions)  been 
delegated  by  Air  Force  System  Project  Offices  to  the  contractor  to  be 
performed  as  part  of  the  normal  system  development  process.  The 
engineer  is  consequently  presented  with  not  or  at  least  only  very  gross 
manpower  requirements  as  part  of  his  initial  design  criteria.  This  has 
led  to  the  present  situation  in  which  systems  are  developed  without  ade¬ 
quate  consideration  of  personnel  inputs. 
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It  is,  therefore,  recommended  that  the  Air  Force,  not  the  hardware 
development  contractor,  should  perform  the  initial  and  basic  personnel 
analyses  and  determine  manpower  requirements  for  systems  under 
development;  that  the  Air  Force,  not  the  hardware  contractor,  should 
specify  the  manning  structure  for  the  new  system;  that  the  Air  Force 
should  impose  that  manning  structure  on  the  hardware  contractor  as  a 
design  requirement;  and  that  the  contractor  should  be  forced  to  imple¬ 
ment  that  requirement  in  his  design.  None  of  this  is  done  at  present. 

Since  PRD  presently  has  so  little  effect  on  the  hardware  aspects  of 
subsystem  design,  it  is  obvious  that  the  present  method  of  managing 
personnel  subsystem  development  is  severly  lacking.  The  management 
methodology  described  in  AFSCM  375-5  does  not  do  what  it  is  supposed 
to  do.  Its  actual  implementation  by  the  Air  Force  fails  even  to  agree 
with  the  very. regulations  (e.  g.  ,  AFSCM  375-5,  AFR  30-8)  set  up  by  the 
Air  Force  to  develop  the  personnel  subsystem. 

The  management  methodology  described  in  AFSCM  375-5  requires 
that  during  the  System  Concept  and  Feasibility  stage  of  system  develop¬ 
ment  (see  Figure  1,  p.  31  )  Air  Force  human  factors  specialists  should 
perform  analyses  of  human  performance  and  personnel  requirements  of 
the  system  to  be  developed. 

During  the  Conceptual  Transition  Phase,  a  human  factors  specialist 
is  supposed  to  be  detailed  to  the  System  Project  Office  (SPO)  and  is 
supposed  to  participate  effectively  in  the  identification  and  analysis  of 
system  functions. 

By  the  end  of  the  Conceptual  stage,  Air  Force  human  factors  special¬ 
ists  are  assumed  to  be  in  a  position  to  specify  preliminary  human 
performance  requirements  and  identify  unique  personnel  and  training 
problems. 

Personnel  subsystem  inputs  to  the  Preliminary  Technical  Development 
Plan  (PTDP)  including  human  performance,  personnel  and  training  re¬ 
quirements,  are  supposed  to  become  part  of  the  RFP  for  Phase  IB  of  the 
Definition  stage. 

The  amount  of  human  factors  participation  in  developmental  studies 
performed  during  the  above  precontractor  phases  is  minimal.  The 
analyses  which  AFSCM  375-5  had  intended  to  be  performed  by  Air  Force 
specialists  are  ordinarily  delegated  to  contractor  personnel  in  later 
development  phases.  Since  the  contractor  is  eager  to  arrive  at  a  hard¬ 
ware  configuration  as  soon  as  possible,  the  necessary  personnel  re¬ 
sources  analyses  are  either  not  performed  at  all,  or  if  performed,  are 
hopelessly  late. 


Since  the  problem  is  one  of  management  of  the  personnel  subsystem 
and  timing  of  inputs,  it  cannot  be  solved  by  purely  technical  means, 
such  as  developing  a  "new"  task  analysis  methodology  or  a  "new"  re¬ 
porting  form. 


What  must  be  done: 

(1)  The  analyses  which  AFSCM  375-5  requires  be  performed  by 
Human  Factors  specialists  in  the  phases  prior  to  issuance  of 
an  RFP  must  be  performed  by  Human  Factors  specialists  in 
the  spirit  of,  if  not  to  the  letter  of  AFSCM  375-5. 

(2)  The  results  of  these  analyses  in  the  form  of  at  least  a  prelim¬ 
inary  manning  structure  must  be  included  in  the  RFP  as  a  firm 
design  requirement. 

(3)  The  contractor  proposing  to  develop  a  particular  system  must 
include  in  his  proposal  an  analysis  of  the  effect  of  that  manning 
structure  on  his  hardware  configuration. 

(4)  The  selection  of  the  winning  contractor  must  be  based  partially 
on  his  ability  to  design  hardware  in  accordance  with  that  man¬ 
ning  structure. 

(5)  The  SOW  handed  to  the  selected  contractor  must  include  the 
manning  structure  as  a  firm  design  requirement. 

(6)  The  contractor's  Human  Factors  specialists  must  have  as  their 
major  responsibility  the  task  of  interpreting  the  manning  struc¬ 
ture  to  engineers  in  design-relevant  terms  and  of  insuring  that 
the  equipment  configuration  developed  incorporates  that  manning 
structure  as  a  basic  element. 


(7)  During  contractor  development  of  the  system,  SPO  representa¬ 
tives  must  monitor  design  activities  more  intensively  than  they 
have  done  in  the  past  to  "encourage"  company  management  to 
"allow"  the  participation  of  Human  Factors  specialists  in  the 
design  process. 

(8)  The  contractor  should  be  required  to  demonstrate  that  he  has 
included  personnel  considerations  in  his  design  of  the  system. 

Part  of  the  problem  is  that  until  now  personnel  data  have  been  used 
to  predict  and  describe  what  the  manning  structure  should  be  based  on 
in  the  hardware  configuration.  Since  personnel  inputs  produced  under 
such  an  orientation  have  had  minimal  influence  upon  system  design,  it 
is  necessary  to  consider  a  new  concept  of  system  management  of  per¬ 
sonnel  subsystem  development.  This  concept  has  been  called  Human 
Resources  Engineering  (see  Eckstrand  et  al.  1967). 
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The  essence  of  this  concept  is  that  human  resources  data  (i.  e.  , 
manpower  requirements,  personnel  resources  data  inputs)  must  be  used 
as  a  control  parameter  during  system  design  to  bring  the  equipment  con¬ 
figuration  into  greater  compatibility  with  the  desired  manning  structure. 
Human  Resources  Engineering  (HRE)  conceives  of  personnel  inputs  as 
influencing  the  total  system  configuration  (including  hardware)  in  the 
same  way,  although  perhaps  not  the  same  extent,  as  do  equipment  inputs. 

This  requires  not  so  much  a  change  in  procedure  as  it  does  a  change 
in  implementation.  In  general,  the  methodology  required  to  exercise 
HRE  control  over  equipment  design  does  not  differ  greatly  from  that 
presently  required  for  the  development  of  personnel  data.  The  new  con¬ 
cept  assumes,  however,  that  the  methodology  which  AFSCM  375-5  re¬ 
quires  will  be  fully  implemented  and  that  it  will  be  directed  at  influencing 
not  only  the  personnel  subsystem  but  also  the  equipment  subsystem. 

It  may  be  objected  that  the  required  personnel  and  human  performance 
analyses  cannot  be  performed  prior  to  issuance  of  the  RFP  because  of 
lack  of  data  and  that  consequently  a  definitive  manning  structure  cannot  be 
provided  to  the  contractor.  This  is  merely  an  excuse. 

While  it  may  appear  as  if  at  very  early  stages  comparatively  little 
system  information  is  available,  it  is  possible  for  the  PS  engineer  to 
make  many  deductions  concerning  personnel  requirements  based  on  even 
a  small  amount  of  information.  Knowing  the  general  class  of  system  re¬ 
veals  much  about  the  kind  of  equipment  and  personnel  functions  to  be 
performed.  Few  systems  in  development  are  complete  technological 
innovations  without  any  similarity  to  systems  that  have  preceded  it.  (If 
this  were  so,  engineers  could  no  longer  design  as  rapidly  as  they  do.  ) 

The  data  available  from  predecessor  systems  can  be  used  to  arrive  at 
valuable  conclusions. 

Note  that  the  system  engineer  starts  his  analyses  with  little  more 
information  about  the  prospective  system  than  the  PS  engineer  has. 

It  should,  therefore,  be  possible  to  derive  from  that  initial  informa¬ 
tion  a  preliminary  mission/event  analysis,  the  functions  and  tasks  (to  a 
certain  level  of  detail)  to  be  performed  by  personnel  during  the  mission, 
who  should  perform  these,  the  number  of  personnel  needed  to  perform 
the  mission  sequence,  the  skills  required,  etc. 

In  the  performance  of  this  analysis,  the  Air  Force  Human  Factors 
specialist  will  find  it  necessary  to  participate  in  system  development 
in  a  very  vigorous  manner,  since  military  engineering  personnel,  like 
their  contractor  counterparts,  may  be  largely  unaware  of  or  indifferent 
to  human  factors. 
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Outputs  of  the  personnel  analysis  must  be  included  in  the  personnel 
section  of  the  PTDP.  Human  resources  requirements  at  a  level  of 
specificity  quivalent  to  that  of  equipment  description  must  be  included 
in  the  PTl  P  to  insure  proper  consideration  of  these  requirements  by 
the  hardw  r  i  designer. 

The  RiP  and  SOW  must  also  include  the  following: 

(a)  Description  of  the  manning  structure  which  the  detailed  equip¬ 
ment  design  will  fit.  Requirements  must  be  specified  for: 

(1)  Maximum  number  of  operating/ maintenance  personnel  to 
be  included  in  the  crew  by  job  position.  Such  a  maximum 
number  for  system  personnel  constrains  design  by  speci¬ 
fying  that  any  system  configuration  requiring  personnel  in 
addition  to  that  number  will  be  unsatisfactory.  Job  posi¬ 
tions,  when  these  are  described  in  terms  of  Air  Force 
positions,  should  be  referenced  to  the  closest  civilian 
equivalent. 

(2)  Functions  and  tasks  to  be  performed  and  their  interrela¬ 
tionships.  Although  the  term  "manning  structure"  usually 
implies  only  numbers  of  personnel  and  very  general 
descriptions  of  job  positions  and  skill  level,  the  term  as 
used  in  this  report  implies  a  detailed  description  of  system 
operations  as  these  are  pe rformed  by  personnel  or  influence 
their  performance.  Since  the  designer  is  oriented  toward 
specific  operations,  function  and  task  description  should  be 
phrased  in  terms  of  events  to  be  performed  in  the  system 
mission. 

(3)  The  skill  level  required  for  each  job  position.  In  describ¬ 
ing  skill  level  to  the  hardware  designer,  it  i3  essential 
that  this  level  be  related  to  the  specific  tasks  to  be  per¬ 
formed  by  personnel  in  that  system.  In  addition,  the  degree 
of  skill  required  should  be  described  in  terms  of  the  amount 
of  supervision  required  to  perform  the  job. 

(4)  Length  (e.  g.  ,  three  months)  and  type  of  training  (in  terms 
of  capability  to  perform  specific  system  operations)  must 
also  be  specified. 

(b)  Backup  data  in  terms  of  detailed  mission/event  analyses  and  time 
line  plots  should  be  supplied  in  the  form  of  an  appendix  to  the  RFP. 

The  potential  contractor  should  be  required  to  specify  the  effect  of 
these  requirements  in  terms  of  the  hardware  design  concept  he  is  proposing 
and  to  indicate  alternative  design  configurations  that  will  satisfy  these 
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requirements.  He  must  indicate  the  impact  of  the  requirements  in  terms 
of  expected  system  performance,  reliability,  cost  and  safety.  Where  it 
is  impossible  for  him  to  design  to  personnel  requirements  he  should  in¬ 
dicate  why  and  how,  in  his  opinion,  the  preliminary  manning  structure 
should  be  revised. 

The  PS  information  to  be  included  in  the  winning  contractor's  SOW 
should  include  the  same  requirements  included  in  the  RFP.  However,  it 
should  be  possible  to  make  these  requirements  more  specific,  since  the 
contractor  has  included  in  his  response  details  of  the  anticipated  system 
configuration  which  can  be  applied  to  refine  the  PS  requirements.  For 
this  reason,  the  original  RFP  requirements  should  be  re-examined  by 
the  SPO  in  terms  of  the  winning  contractor's  response.  Descriptions  of 
functions,  tasks  and  skill  level  characteristics  can  be  made  more  detailed 
by  phrasing  them  in  terms  of  the  contractor's  anticipated  system  config¬ 
uration. 

The  implementation  of  such  a  program  will,  of  course,  generate 
opposition  from  contractors.  The  cry  will  arise,  reminiscent  of  some 
comments  by  subjects,  that  the  engineer's  freedom  to  design  creatively 
is  being  abridged.  Such  objections  are  invalid,  since  the  amount  of 
creativity  in  the  engineer's  design  is  limited  by  his  reliance  on  experien¬ 
tial  stereotypes. 

These  recommendations  will,  of  course,  work  only  if  the  Air  Force 
personnel  specialists  analyzing  system  requirements  prior  to  the  issuance 
of  an  RFP  are  highly  qualified,  if  they  have  time  to  analyze  that  require¬ 
ment  not  only  in  human  factors  ter  ins,  but  also  in  terms  of  their  hardware 
consequences  and  their  interaction  with  cost  and  schedule,  and  if  they  do 
not  become  bogged  down  in  paper  work.  Naturally,  stringent  personnel 
requirements  should  be  imposed  only  on  systems  which  will  ope  rationally 
stress  system  personnel. 

The  implementation  of  this  program  will  also  require  a  substantial 
increase  in  the  number  of  Air  Force  personnel  specialists  and  their  assign¬ 
ment  to  SPO  offices.  The  Air  Force  must  be  sufficiently  convinced  of  the 
necessity  for  incorporating  personnel  requirements  into  design  to  spend 
the  money  needed  to  actually  do  the  job  and  to  provide  the  authority  to  in¬ 
sure  that  the  job  gets  done. 

During  Phase  IB  (contractor  definition),  personnel  subsystem  activi¬ 
ties  performed  in  the  contractor's  facility  must  emphasize  the  interpre¬ 
tation  of  PRD  in  design -re levant  terms. 

Because  the  RFP  and  the  SOW  contain  firm  requirements  describing 
the  new  system's  manning  str  cture,  the  role  of  the  contractor's  PS 
engineer  during  development  must  change  from  what  it  has  been.  Pre¬ 
sently,  the  contractor's  PS  engineer  spends  most  of  his  time  attempting 


-  98  - 


to  predict  a  manning  structure  which  is  implicit  in  an  already  established 
equipment  configuration.  The  result  is  that  his  efforts  dissipate  them¬ 
selves  in  largely  useless  paper  work. 

Under  the  new  HRE  concept,  since  the  desired  manning  structure  has 
already  been  specified  in  the  RFP  and  SOW,  it  should  no  longer  be  neces¬ 
sary  to  perform  these  analyses.  Rather  the  emphasis  must  shift  to: 

(1)  Interpretation  of  the  manning  structure  requirements  in  terms 
of  what  they  mean  for  equipment  design. 

(2)  Performance  of  further  analyses  to  determine  more  detailed 
personnel  requirements. 

(3)  Analysis  to  determine  that  the  detailed  elements  of  the  design 
configuration  (e.  g.  ,  controls  and  displays,  work  place  layout, 
etc.  )  are  compatible  with  the  detailed  personnel  requirements. 

All  of  this  means  that  the  contractor's  Human  Factors  engineer  will 
have  to  become  more  intimately  involved  with  the  hardware  aspects  of 
the  man-machine  interface  and  participate  more  vigorously  in  the  design 
process.  He  must  become  more  concerned  about  such  things  as  the 
number  and  type  of  controls  and  displays,  the  procedures  system  person¬ 
nel  must  perform,  the  amount  and  type  of  feedback,  communication,  per¬ 
formance  job  aids,  etc.  All  of  these  must  be  considered  in  terms  of 
whether  they  permit  the  specified  number  of  personnel  with  particular 
levels  of  skill  and  training  to  perform  efficiently. 

The  individual  PRD  inputs,  the  information  they  should  provide,  and 
how  this  information  should  be  presented  ’S  described  in  a  series  of  ex¬ 
hibits  in  Appendix  IV. 

During  this  development  effort,  SPO  representatives  can  make  a 
major  contribution  to  the  efficiency  of  the  contractor's  personnel  analyses 
by  "showing  the  flag,"  as  it  were.  Periodic  inspection  visits,  conferences 
and  monthly  HRE  progress  reports  from  the  contractor  to  the  SPO  can  do 
much  to  foe  us  attention  on  the  importance  of  per  sonnel -  related  activities. 
Since  it  is  unlikely  that  anything  other  than  a  major  educational  effort  will 
change  the  engineer's  deep-seated  indifference  to  personnel  factors,  the 
next  best  solution  is  to  endow  these  factors  with  the  aura  of  authority. 

A  good  deal  depends  on  the  quality  of  the  Air  Force  and  contractor 
personnel  subsystem  specialists.  Their  competency  in  interpreting 
behavioral  requirements  to  engineers  is  an  indispensable  factor  in 
arriving  at  a  solution. 


The  recommendations  made  in  this  report  cannot  be  implemented 
overnight.  In  the  meantime,  niu^h  more  needs  to  be  done  in  the  way 
of  research  to  provide  the  Human  Factors  specialist  with  the  tools  that 
will  permit  him  to  translate  behavioral  requirements  into  hardware 
equivalents. 

Two  areas  of  research  are  most  important.  These  are: 

(1)  Determination  of  the  information  required  in  order  to  perform 
the  pre-RFP  analyses  needed  to  specify  detailed  manpower 
requirements  in  tne  RFP 

(2)  Determination  of  those  skill  level  parameters  which  are  mean¬ 
ingful  for  design  and  translation  of  these  parameters  into  eng¬ 
ineering  design-relevant  terms. 

The  pre-RFP  analyses  needed  to  specify  manpower  requirements 
have  generally  been  phrased  in  some  variation  of  the  function/task 
analysis  methodology  described  by  Van  Cott  and  Altman  (1956)  and 
Rabideau  et  al.  (1961).  This  methodology  is  excessively  vague.  More¬ 
over,  it  has  never  been  validated  with  reference  to  the  very  early  (i.e.  , 
pre-RFP)  system  development  phases  in  which  it  is  presumed  to  be 
utilized.  One  reason  for  the  Air  Force's  failure  to  perform  the  needed 
manpower  analyses  in  these  early  developmental  phases  may  be  the 
difficulty  of  applying  the  function/task  analysis  methodology  in  these 
phases. 

Specifically,  therefore,  it  is  recommended  that  an  empirical  study 
be  performed  in  which  the  following  questions  would  be  answered: 

(1)  What  kinds  of  information  are  needed  by  the  system  engineer 
and  the  Human  Factors  specialist  in  order  to  develop  man¬ 
power  requirements  information  in  this  early  period? 

(<:»  What  kinds  of  deductions  leading  to  the  determination  of  man¬ 
ning  structures  can  be  made  from  very  early  system  information? 

(3)  How  should  these  manpower  analyses  be  perfcrr..?d  in  the  pre- 
RFP  period? 

The  present  study  has  also  demonstrated  the  need  for  translating 
Air  Force  skill  level  descriptions  into  terms  which  are  relevant  to  the 
design  engineer.  Present  skill  level  parameters  (e.g.  ,  capability 
difficulty,  error  rate)  are  oriented  around  behavioral  concepts  which 
do  not  easily  translate  into  design  equivalents.  It  is,  therefore,  sug¬ 
gested  that  skill  level  be  analyzed  with  the  aim  of  determining  (1)  ho.v 
does  the  engineer  conceptualize  skill  parameters  and  the  skill  continuum 
(i.e.  ,  how  does  he  differentiate  classes  of  skill  capability)?  (2)  how  dc 


the  engineer's  skill  level  parameters  relate  to  those  desired  in  behav¬ 
ioral  terms?  and  (3)  which  of  these  parameters,  phrased  in  equipment- 
oriented  terms,  will  exercise  a  significant  influence  on  equipment 
design? 

More  generally,  we  would  like  to  press  for  more  empirical  research 
on  the  design  engineer,  particularly  with  regard  to  his  characteristic 
ways  of  attacking  design  problems.  The  design  engineer  is  a  focal 
point- -perhaps  the  most  important  one --of  our  technology.  Despite  this 
and  the  previous  research  performed  by  the  authors,  very  little  ia  known 
about  him.  Much  more  needs  to  be  known.  This,  of  course,  is  where 
all  research  leads:  to  the  need  for  more  research. 
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APPENDIX  I 


ABBREVIATED  SCENARIO  OF  EQUIPMENT  AND  PERSONNEL 
INPUTS  PROVIDED  TO  ENGINEER-SUBJECTS 

NOTE  TO  THE  READER 

The  length  of  some  of  the  equipment  and  personnel  inputs  provided 
to  engineer-subjects  in  this  study  is  so  extensive  that  to  have  included 
all  inputs  in  their  entirety  would  huve  made  this  report  extremely 
unwieldy.  Consequently,  less  important  inputs  have  been  compressed 
by  reproducing  only  that  material  which  is  illustrative  of  the  general 
character  of  the  input.  Where  an  input  has  been  compressed,  it  has 
been  so  indicated  by  brackets,  £  3*  Inputs  considered  by  the 

authors  to  be  of  major  importance  have  been  reproduced  in  their  entirety. 

Where  the  purpose  of  a  particular  input  or  part  of  an  input  may 
have  been  unclear  without  additional  explanation,  explanatory  material 
has  been  added  in  brackets. 

INTRODUCTORY  SESSION 

Instructions  for  Participating  Engineers 

The  United  States  Air  Force,  through  a  contract  with  The  Bunker- 
Ramo  Corporation,  is  conducting  a  study  to  determine  how  engineers  make 
use  of  the  information  they  are  given  (or  develop  themselves)  to  design 
a  subsystem.  Since  any  subsystem  is  conqposed  of  two  basic  elements, 
equipment  and  people,  we  assume  that  the  engineer  has  available  to  him 
two  kinds  of  information:  information  about  equipment  requirements, 
characteristics,  functions,  etc.;  and  information  about  or  relevant 
to  the  personnel  who  will  operate  and  maintain  that  equipment. 

The  Air  Force  is  interested  in  the  engineer's  use  of  both  types  of 
information,  but  it  is  particularly  interested  in  the  use  made  of 
personnel  information.  The  reason  is  that  although  the  engineer  is 
accustomed  by  training  and  experience  to  using  equipment  information, 
personnel  information  is  relatively  unfamiliar  to  him.  The  Air  Force 
is  interested  in  finding  out  if  the  personnel  information  it  supplies 
to  the  engineer  is  used  by  him,  and  especially  if  that  information 
makes  a  difference  to  the  overall  subsystem  design. 

4 

To  answer  these  questions,  it  is  necessary  to  present  this  informa¬ 
tion  in  the  context  of  the  development  of  some  subsystem.  Short  of 
actually  conducting  the  study  during  the  development  of  actual  equipment, 
which  would  take  an  excessive  length  of  time,  the  only  other  way  of 
creating  a  developmental/design  context  was  to  reproduce  or  simulate 
the  development  of  a  subsystem  in  a  highly  abbreviated  form.  This 
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simulation  will  naturally  have  to  be  of  the  paper  and  pencil  variety. 
However,  this  does  not  concern  us  too  much  since  we  are  interested  in 
studying  the  very  early  design  phases,  before  detailed  drawings  are 
made  and  equipment  fabricated. 

What  we  have  done  is  to  take  an  already  developed  (operational) 
subsystem,  extract  the  items  of  information  vised  in  its  development 
and  arrange  them  in  a  sequence  which  corresponds  to  the  way  in  which 
they  were  actually  used  to  design  that  subsystem.  The  subsystem 
selected  by  the  Air  Force  is  the  propellant  loading  subsystem  for  a 
liquid  fueled  two  stage  missile.  The  reason  you  were  selected  as 
subjects  for  this  study  is  because  you  have  helped  to  design  similar 
subsystems . 

Obviously,  such  a  propellant  transfer  subsystem  is  a  very  large 
one ,  and  it  would  be  impractical  to  ask  you  to  try  to  redesign  the 
entire  subsystem.  What  we  have  done  is  to  select  only  one  function 
of  that  subsystem  -  fueling.  In  addition,  we  have  arbitrarily  simpli¬ 
fied  the  subsystem  by  ignoring  many  equipments  and  operations  which  you, 
who  are  experienced  in  the  design  of  such  subsystems ,  will  obviously 
note.  Do  not  be  disturbed  by  this.  The  subsystem  is  supposed  only  to 
represent  propellant  subsystems  in  general. 

The  general  manner  in  which  we  will  work  is  like  this.  £  Description 
of  test  procedure  follows. ^ 

One  thing  I  should  emphasize.  The  questions  we  ask  and  the  tasks 
we  ask  you  to  perform  are  not  tests  in  the  conventional  sense  of  the 
word.  The  word  "test"  suggests  that  only  one  correct  response  can  be 
made  to  these  design  problems.  In  these  design  problems  there  are  no 
correct  or  incorrect  answers,  because  only  you  can  tell  us  what  the 
correct  answer  should  be.  For  this  reason  it  is  most  important  that, 
although  we  cannot  completely  provide  all  the  conditions  under  which 
you  ordinarily  design,  you  respond  to  these  problems  In  the  way  in 
which  you  would  ordinarily  solve  an  actual  design  problem.  Remember 
that  the  value  of  the  Information  you  provide  depends  on  how  accurately 
it  reflects  the  way  you  ordinarily  design  on  the  job.  Remember  also 
that  this  is  not  a  test  of  your  ability,  although  we  want  you  to  do 
your  best.  We  would  not  have  selected  you  to  do  this  work  if  we  did 
not  think  you  could  do  it. 

We  will  probably  meet  cnce  a  week  and  the  schedule  will  be  adapted 
to  your  convenience.  Between  our  sessions  you  may,  if  you  .wish,  refer 
to  the  inputs  you  have  been  given.  However,  this  part  of  the  study  is 
purely  voluntary.  During  your  sessions  and  in  the  interim,  you  may 
consult  anyone  In-plant  from  whom  you  wish  additional  information.  We 
do  ask  one  thing  of  you,  however;  do  not  confer  with  your  fellow  parti¬ 
cipants  in  the  study  on  any  aspect  of  the  study.  To  do  so  would  seriously 


-  103  - 


reduce  the  value  of  the  result:; . 


Are  there  any  qm  tions? 


Here  is  the  Statement  of  Work  which  you  as  the  project  engineer 
for  the  PTPS  will  ha\^  to  design  to.  We  would  like  you  to  take  it 
with  you  and  to  examine  it  carefully.  Please  bring  it  with  you 
when  you  return  for  the  first  session. 


STATEMENT  OF  WORK 


PROPELLANT  TRANSFER  AND  PRESSURIZATION  SYSTEM  (PTPS) 

1.0  PURPOSE  AND  SCOPE 
1.1  Purpose 

Hiis  Statement  of  Work  (SOW)  establishes  the  requirements 
for  the  conceptual  design  of  a  propellant  transfer  and  pressurization 
subsystem  ( FTPS) ,  including  any  peculiar  handling,  checkout,  maintenance 
and  instrumentation  equipment  required.  The  PTPS  is  to  be  used  as  an 
integral  part  of  the  Titan  X  Space  Launch  Vehicle  (SLV).  The  Titan  X 
SLV,  which  is  a  two-stage  liquid- fueled  rocket  vehicle,  will  provide 
the  Air  Force  with  the  capability  of  lifting  both  manned  and  unmanned 
systems  into  either  an  earth  or  lunar  orbit.  The  SLV  itself  is  currently 
being  designed  to  be  launched  from  fixed  surface  launchers  already  avail¬ 
able  at  Vandenberg  AFB. 

The  PTPS  to  be  designed  will  provide  facilities  for  receiving 
propellants  from  GFE  railroad  cars,  for  transferring  fuel  from  these 
cars  to  ready  storage  vessels  (RSV),  for  storing  the  propellants  in 
the  RSV  for  a  period  of  30  days,  and  for  transferring  the  stored  pro¬ 
pellants  to  the  SLV  tanks.  The  propellant  to  be  transferred  will  consist 
of  a  50$  mixture  of  hydrazine  and  unsynmetrical  dime thy lhydrazine . 

Because  of  the  highly  volatile  nature  of  these  chemicals ,  provisions 
for  safety  of  personnel  and  equipment  will  have  the  highest  design 
priority. 


The  contractor  will  note  that  no  provisions  have  been  included 
in  the  3(M  for  work  beyond  the  conceptual  design  stage  (phases  1A  and 
IB) .  The  government  intends  to  negotiate  a  follow-on  contract  for  test 
and  production  of  the  PTPS  subsystem  based  on  an  evaluation  of  the 
effectiveness  of  the  designs  provided  at  the  conclusion  of  the  present 
contract. 

1.2  Scope 

The  contractor  will  design  and  develop  a  system  having  the 
following  capabilities: 

1.  To  provide  a  capability  of  receiving  propellants  from 
transport  vehicles  and  to  store  them  in  storage  tanks. 

2.  To  provide  a  capability  for  transferring  propellants 

into  either  of  the  missile  propellant  tanks  find  to  return  the  propellants 
to  the  storage  tanKS. 


'  -  ""-wlooKj, 
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3.  To  perform  (2)  above  while  accurately  measuring  the  amount 
of  propellants  being  transferred  and  while  controlling  propellant  temp¬ 
erature. 


4.  To  add  or  remove  incremental  amounts  of  propellants  from 
Stage  I  or  Stage  II  missile  tanks  in  order  to  optimize  the  load  under 
changing  temperature  conditions. 

5-  To  provide  a  means  of  distributing  nitrogen  within  the  PTPS 
to  provide  blanket  pressure  and  to  purge  the  system. 

Figures  1A  and  2A  present  functional  flow  diagrams  of  basic 
PTPS  functions.  These  describe  only  fueling  functions,  since  oxidizer 
functions  are  essentially  identical. 

2,0  APPLICABLE  DOCUMENTS 

General  -  The  following  documents  form  a  part  of  this  specifica¬ 
tion  to  the  extent  specified  herein.  In  the  event  of  conflict  between 
the  requirements  of  this  specification  and  any  document  referenced  herein, 
the  requirements  of  this  specification  shall  govern. 


Specifications 

Military 

MTL-H-6011 

-  Nitrogen,  Liquid  and  Gas 

mil-P-26539 

-  Propellant,  Nitrogen  Tetroxide 

MEL-P- 27401 

-  Propellant,  Nitrogen  Pressurizing 

MIL-P-27402 

-  Propellant,  Hydrazine  -  UnsymmetriceJL 
Dimethylhydrazine 

MIL- D- 1000 

1  Mar  6 5 

-  Military  Specification,  Drawings, 
Engineering  and  Associated  Lists 

MIL-M-26512 

13  Dec  63 

-  Maintainability  Requirements  for 
Aerospace  Systems  and  Equipment 

MIL-H- 27894 

9  Jan  63 

-  Human  Engineering  Requirements  for 
Aerospace  Systems  and  Equipment 

Standards 

ASME  Boiler 
and  Pressure 
Code 

-  Section  VIII  Construction  of  Unfired 
Pressure  '/essels,  Current  Edition 
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FIPS  Second  Level  Functions 


MIL-STD-803-A1  -  Human  Engineering  Design  Criteria  for 

Aerospace  Systems  and  Equipment.  Part  1 
Aerospace  System  Ground  Equipment 


AFTO  I1C-1-6 


MIL-STD-210A 
2  Aug  57 

MIL-STD-721 
2  Aug  62 

MIL-STD-756 
15  May  63 

MIL-STD-778 
9  Apr  64 

MIL-STD-785 
30  Jun  65 

2.1  Other  Publications 


-  General  Safety  Precautions  for  Missile 
Liquid  Propellants 

-  Climate  Extremes  for  Military  Equipment 

-  Definitions  for  Reliability  Engineering 

-  Reliability  Predictions 

-  Terms  and  Definitions  of  Maintainability 


Requirements  for  Reliability  Programs 
(for  Systems  and  Equipments) 


'Hie  following  documents  form  a  part  of  this  specification  to 
the  extent  specified  here',n.  Hie  issue  in  effect  on  date  of  this  SOW 
shall  apply. 


AF3CM  80-3 
MIL-HDBK-217 


AFSCM  375-I 
1  Jun  64 

AFSCM/ AFLCM 

310-1 

15  Mar  feA 


-  Handbook  of  Instructions  for  Aerospace 
Personnel  Subsystem  Designers 

-  Reliability  Stress  and  Failure  Rate 
Data  for  Electronic  Equipment 

-  Configuration  Management  during 
Definition  and  Acquisition  Phases 

-  Management  of  Contractor  Data  and  Reports 


3.0  ENGINEERING  INSPECTIONS 

3.1  Preliminary  Design  Review 

Ihe  contractor  shajl  conduct  a  prelim'1  nary  design  review  not 
later  than  60  days  subsequent  tc  award  of  contract.  This  review  shall 
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be  in  accordance  with  AFSCM  375- and  shall  be  subject  to  approval 
of  the  Titan  X  SLV  Project  Office. 

3.2  Critical  Design  Review 

Hie  contractor  shall  conduct  a  critical  design  review  180  days 
after  award  of  contract.  This  review  shell  be  in  accordance  with  AFSCM 
375-1 ,  and  shall  be  subject  to  approval  of  the  Titan  X  SLV  Project  Office. 

3*3  Final  Acceptance 

Final  acceptance  of  the  contractor's  work  shall  be  indicated  by 
accomplishment  of  a  DD  Form  250  reflecting  technical  acceptance  of  the 
designs  provided  by  the  contractor  and  completion  of  all  contractual 
requirements  as  specified  in  this  SOW  and  associated  documents.  In  the 
event  there  sure  exceptions  to  acceptance  reflected  on  the  DD  Form  250 
or  attachments  thereto,  the  contractor  shall  be  required  to  correct 
all  exceptions  as  specified  within  the  time  limit  mutually  agreed  upon 
during  the  execution  of  the  DD  Form  250. 

4.0  PERFORMANCE  REQUIREMENTS 

4.1  Comgonents 

The  PTjPS  and  its  component  parts  may  incorporate  those  tech¬ 
nological  advancements  which  can  be  utilized  without  unnecessary  develop¬ 
ment  risks  or  expense  inappropriate  to  performance  gain.  PTPS  equipment 
and  components  fall  into  four  categories:  liquid,  vent,  nitrogen  and 
electrical. 


Electrical  components  will  be  designed  to  operate  from  28  VDC . 
Components  are  to  be  either  hermetically  sealed  or  continuously  pressur¬ 
ized  with  nitrogen  gas  to  a  minimum  oi  50  inches  of  water  pressure  to 
prevent  contamination. 

Liquid  components,  defines  as  those  items  normally  in  direct 
contact  with  propellants,  shall  be  designed  to  withstand  an  operating 
pressure  of  225  PSIG,  proof  pressure  of  350  PSIG,  burst  pressure  of 
900  PSIG.  All  liquid  components  are  to  be  designed  to  have  a  self-arain- 
ing  capability  or  are  to  be  provided  with  drains.  ^Further  equipment 
details  follow. 3 

The  system  shall  have  the  capability  of  transferring  fuel  from 
the  RSV  to  SLV  tanks  at  a  rate  of  >0  GPM  to  200  GPM.  Tanking  of  the 
two  SLV  stages  shall  be  performed  sequentially. 
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4.2  'Time  Requirements 

He  system  is  to  be  so  designed  that  fuel  and  ozidizer  can  be 
loaded  into  the  3LV  tanks  within  a  90  minute  period,  once  the  requirement 
to  transfer  propellants  has  been  given.  Maximum  time  requirements  for 
the  individual  transfer  functions  are  given  below  (only  for  fueling,  since 
oxidizer  functions  are  considered  to  be  identical): 

(a)  Transfer  fuel  from  RR  car  to  RSV  -  4  hours 

(b)  Transfer  fuel  from  RSV  to  SLV  -  90  minutes 

All  times  are  for  maximum  propellant  loads. 

5.0  ENVIRONMENTAL  REQUIREMENT^ 

5.1  Clljpatlc 

The  PTPS  shall  be  designed  to  operate  under  the  following 
conditions : 

(lj  Ambient  temperature 

(a)  Operating  -  32F  -  90F 

(b)  Non-operating  -  20F  to  11 5 F 

(2)  humidity 

He  equipment  shall  be  operable  during  and  after  subjection 
to  ambient  humidity  of  95$- 

(3/  Barometric  pressure 

(a)  Operating  and  non-operating  -  sea  level  to  approx¬ 
imately  10,000  feet 

The  PTPS  shall  incorporate  provisions  designed  to  protect 
against  salt,  sand,  and  dust  in  accordance  with  the  requirements  01' 

MIL  STD  210A.  Wind,  iceload,  rainfall,  fungi,  provisions  are  not 
applicable. 

5.2  Mechanical 


He  FTPS  shall  be  designed  to  meet  the  following  mechanical 
conditions: 
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(1)  Vibration  --  50-100  cycles  for  15  seconds 

(2)  Shock  —  minimum  lOg  over  burst  pressure 
6.0  SERVICE  LIFE 


The  design  and  installation  of  the  PTPS  shall  be  such  that  a  minimum 
operational  life  of  10  years  with  required  maintenance  will  be  achieved. 

7.0  PERSONNEL  SUBSYSTEM 


7.1  Manpower  Requirements 

Oe  following  was  created  for  and  presented  to  the  high  skill, 
low  number  group  (  I  }  only.] 


The  contractor  shall  design  arid  develop  the  PUPS  for  operation 
and  maintenance  by  Air  Force  personnel.  It  is  desirable  that  only  a 
minimum  number  of  personnel  be  required  to  man  the  system.  This  criterion 
shall  have  top  priority  in  any  design  situation  in  which  skill  level 
and  number  of  personnel  must  be  traded  off.  It  is  anticipated  that 
operational  personnel  will  be  a  small  number  of  highly  trained  special¬ 
ists  who  possess  considerable  skill  in  the  performance  of  their  duties. 

It  is  anticipated  that  uot  more  than  15  personnel  will  be  available  to 
operate  and  maintain  the  system.  Seventy-five  percent  of  these  personnel 
will  be  5  and  7  level  Air  Force  personnel;  the  remaining  25 %  will  br 
3  level  Air  Force  personnel.  In  view  of  the  hazardous  nature  of  the 
system,  however,  situations  in  which  human  error  could  occur  are  to  be 
avoided.  For  this  reason  the  PITS  shall  be  designed  to  applicable  sections 
of  MIL  STD  803A-1. 

Oe  following  was  created  for  and  presented  to  tne  low  skill, 
high  number  of  personnel  group  ( II  )  only.] 


The  contractor  shall  design  and  develop  the  FTPS  for  operation 
and  maintenance  by  Air  Force  personnel.  A  primary  goal  in  design  of  the 
PEPS  is  that  these  personnel  shall  require  a  minimum  amount  of  training 
or  skill  in  the  performance  of  their  duties.  Every  effort  shall  be  made 
to  avoid  the  necessity  for  complex  manual  operations.  It  is  anticipated 
that  not  more  than  20  personnel  will  be  available  to  operate  surd  maintain 
the  system.  Seventy-five  percent  will  be  3  level  Air  Force  personnel; 
the  remaining  2S it  will  be  5  and  7  level  Air  Force  personnel.  In  view  of 
the  hazardous  nature  of  the  system,  situations  in  which  human  error 
could  occur  are  to  be  avoided.  For  this  reason,  the  FTPS  shall  be 
designed  to  applicable  section  a  of  MIX  STD  0O3A-1.  In  any  design 
situation  in  which  skill  level  and  number  of  personnel  must,  be  traded 
off,  the  requirement  for  minimum  Bkill  level  shall  be  accorded  first 
priority. 
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Hie  following  is  a  definition  of  the  Air  Force  skill  levels 
referenced  in  this  statement  of  work. 

3  level  --  Performs  simple  manual  operations  readily  (without 
assistance)  but  may  require  assistance  (supervision  or  use  of  manuals) 
with  more  complex  operations,  particularly  those  involving  a  combination 
of  tasks  or  requiring  significant  decisions  involving  extrapolation  of 
data  or  Judgment.  Performs  simple  responses  quickly,  shows  hesitation 
or  significant  delay  with  more  complex  ones.  Has  a  low  error  probability 
(1-5$)  for  simple  or  moderately  precise  operations,  which  rises  t-o  an 
extremely  high  level  for  complex  operations  (50$). 

5  level  --  Performs  simple  tasks  and  those  requiring  moderate 
precision  with  little  difficulty  but  may  require  assistance  (supervision 
or  use  of  a  check-list)  with  more  complex  operations,  particularly  those 
involving  significant  decisions  or  Judgments  requiring  extrapolation  of 
data.  Performs  moderately  precise  responses  quickly  and  with  assurance, 
but  shows  hesitation  or  delay  with  more  complex  ones.  lias  a  very  low 
error  probability  for  staple  or  moderately  complex  operations  (l-?$) 
which  rises  to  a  significant  error  rate  for  highly  complex  operations  (20$). 

7  level  --  Display:,  little  difficulty  in  performing  all  opera¬ 
tions  required  including  those  of  a  nature  involving  Judgment  and  extra¬ 
polation  of  data.  Little  or  no  supervision  required.  Responses  are 
quick  and  assured,  requiring  no  assistance  from  others  or  from  manuals/ 
checklists.  Has  extremely  low  error  probability  for  siaple  and  moderately 
complex  operations  (  ,1$)  which  rises  to  approximately  5$  for  highly 
complex  ones. 

The  k  level  requires  administrative  skills  which  are  not 
significant  for  PTPS  operations. 

7.2  Information  Provided 


The  contractor  will  develop  and  maintain  analytical  data  in 
the  form  of  task  and  equipment  information  which  will  define  the  inter¬ 
relationship  of  functions  to  be  performed  by  systems,  people  and  hardware. 
This  material  will  not  duplicate  other  analytical  efforts.  Use  information 
will  contain  a  description  of  personnel  tasks  and  skills  required  to 
operate,  maintain  and  control  the  PIPS .  The  contractor  shall  provide  to 
his  Engineering  Department  the  following  inputs: 

(1)  Personnel/ equipment  task  analysis; 

(2)  Human  engineering  analyser; 

(3)  Quantitative  and  Qualitative  Personnel  Requi remrr.t  s 
Information  (QQPRl); 
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(4)  Training  Requirements  Analyses. 


7*3  Human  Engineering 

As  outlined  in  MIL-H-2789^A;  the  contractor  will  apply  human 
engineering  to  hardware  and  system  design  to  assure  optimum  operation 
and  maintenance,  utilization  of  the  human  as  a  component  in  the  system, 
and  reduction  of  tasks  affected  by  human  limitations  to  a  minimum.  This 
will  include  human  design  considerations  for  maintenance,  operations, 
communications,  illumination,  noise  level,  reliability,  safety,  climate 
and  environment.  Studies  and  recomnendations  will  be  directed  by  Titan 
X  SLV  Project  Office  for  the  improvement  of  procedures  and  design  as 
inefficient  operation  situations  are  detected. 

8.0  SAFETY 

Safety  engineering  will  be  a  priue  consideration  in  the  design  of 
the  PTPS.  Personnel  safety  requirements  shall  be  in  accordance  with 
AFTO  11C-1-6.  All  designs  shall  incorporate  maximum  protection  for 
operating  and  maintenance  personnel  against  hazardous  conditions. 
Adequate  provisions  shall  be  made  to  warn  and/or  protect  personnel  and 
equipment  against  injury  and  damage.  All  designs  shall  be  reviewed  by 
qualified  safety  engineers. 

9.0  RELIABILITY 

9.1  Requirements 

'Hie  availability  of  the  PTPS,  defined  in  terms  of  being  able 
to  initiate  propellant  transfer  when  required,  shall  be  .999®*  The 
reliability  of  the  PTPS,  defined  in  terms  of  its  being  able  to  complete 
propellant  transfer  within  previously  stated  time  requirements,  given 
that  transfer  can  be  initiated,  shall  be  not  less  than  .9950* 

9.2  Prediction 


An  initial  prediction  of  reliability  performance  shall  be 
submitted  to  the  procuring  activity  no  later  than  60  days  after  award 
0/  contract.  A  revised  reliability  prediction  shall  be  issued  no  later 
than  every  90  days  fhom  the  submission  of  the  initial  report.  A  comparison 
0“  the  predicted  JCBF  with  the  required  MIBF  shall  be  made.  A  separate 
prediction  for  the  reliability  of  human  performance  shall  also  be  made. 
When  the  predicted  figure  is  leas  than  the  requirement,  the  cdntractor 
shall  accomplish  such  changes  in  design,  part  application  and  part  stress 
and  personnel  task  allocation  as  are  necessary  to  raise  the  predicted 
MTBF  to  the  required  value. 
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10.0  MAINTAINABILITY 


The  contractor  shall  establish  a  maintainability  program  in  accord¬ 
ance  with  applicable  sections  of  MLL-M-2f  r>12  and  Appendix  A  thereto.  The 
terms  and  definitions  for  maintainability  not  otherwise  described  or 
delineated  shall  be  in  accordance  with  MIL-STD-778. 

As  a  design  goal  the  PTP5  shall  incorporate  factors  that,  enhance 
its  maintainability  ano  accessibility .  The  maintainability  character¬ 
istics  shall  be  such  as  to  mi. Inline  the  requi rezaents  for  special  tools 
or  support  equipment,  inspection,  servicing,  test,  replacement,  .and  over¬ 
haul  operations  required  to  restore  operational  capability  with  a  minimum 
expenditure  of  time,  men  and  materials.  When  other  factors  prohibit 
compliance  vivh  this  requirement,  special  tools  and  service  equipment 
shall  be  identified.  The  inclusion  of  maintainability  characteristics 
as  an  inherent  feature  shall  occur  simultaneously  with  initial  design 
and  shall  be.cont'  lually  analyzed  and  controlled  throughout  the  develop¬ 
ment  cycle.  The  equipment  shall  be  designed  so  that  the  following  system 
mean  and  maximum  corrective  maintenance  times  shall  not  be  exceeded: 

Mean  Corrective  Maintenance  Time  (*  t) ,  (t. 0  hours 

Maximum  Correct; ve  Maintenance  Time  19.0  hours 
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SESSION  1 


Instructions  To  Participating  Engineers 

The  information  presently  available  to  you  consists  of  the  Statement 
of  Work  (SCW),  which  includes  Figures  2  and  3  (the  top  level  function 
flows  for  fueling)  and  the  list  of  personnel  functions  (including 
Figures  4  and  5  )  which  represent  an  analysis,  based  on  the  SOW,  of  the 
personnel  functions  that  must  be  performed  to  accomplish  FTPS  requirements. 
Lin  this  and  subsequent  instructions  underlined  material  was  provided 
only  to  experimental  subjects. "j 

Based  on  this  information,  we  want  you  to  describe,  in  as  much 
detail  as  possible,  all  the  functions  and  subfunctions  which  must  be 
performed  to  accomplish: 

1.  Transfer  of  ■''■tel  from  the  railroad  car  to  the  storage  tanks; 

2.  Storage  of  fuel; 

3-  Transfer  of  fuel  from  the  storage  tanks  to  the  rocket  tanks. 

We  would  like  this  in  the  form  of  two  flow  diagrams  indicating  the 
sequential  or  parallel  relationships  among  subfunctions.  One  flow  diagram 
would  be  for  transfer  of  fuel  to  the  TSV  including  storage;  the  other 
would  be  for  transfer  of  fuel  from  the  RSV  to  the  rocket  tanks.  On  each 
flow  diagram  you  will  indicate  which  functions  are  to  be  perfonned 
primarily  by  equipment  and  which  primarily  by  personnel.  Do  this  by 
putting  an  X  beside  each  personnel  function. 

Before  you  begin  this  task,  however,  but  after  you  review  the  SCW 
end  the  flow  diagrams,  there  are  a  number  of  questions  I  would  like  you 
to  answer.  1  will  record  your  answers  on  this  tape  recorder. 

1.  Do  you  have  enough  Information  about  system  functions  and 
equipment  requirements  to  accomplish  your  task? 

2.  Do  you  have  enough  information  about  personnel  functions 
involved  in  the  FTPS? 

3.  What  additional  information  would  you  wish  to  have  about  either 
system  or  equipment  functions  or  personnel  functions? 

4.  What  information  would  you  ordinarily  receive  at  this  stage  of 
system  development? 
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_  -figure  4 

Personnel  Functions  -  Transfer  Fuel  To  3SV 
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5.  Hov  do  you  think  the  personnel  requirements  in  the  SCW  will 
affect  your  design?  Do  you  think  they  will  have  any  significant,  effect 
on  your  design?  In  what  way? 

The  following  is  for  experimental  subjects  only:  [control  subjects 
did  not  see  this  section  of  the  instructions /J 

6.  Do  you  find  the  flow  diagrams  of  personnel  functions  (Figures  3A 
and  4 A) useful? 

7.  Would  you  ordinarily  expect  to  receive  information  about 
personnel  functions  at  this  stage  of  system  design? 

8.  Do  you  think  this  Information  is  too  early,  too  late,  or  just 
in  time? 

9«  Could  you  have  derived  the  personnel  information  in  the  flow 
diagrams  on  your  own?  Would  you  ordinarily  have  done  so? 

10.  Do  you  have  any  difficulties  understanding  the  personnel  input? 

11.  Do  you  feel  there  is  enough  information  about  PIPS  requirements 
in  the  SOW  to  develop  these  personnel  functions? 

12.  Which  version  of  the  personnel  functions  do  you  find  more 
useful,  the  list  or  the  flow  diagrams?  Is  there  any  real  difference 
between  them? 

13.  Can  you  apply  the  personnel  input  to  your  design  task? 

14.  What  design  implications  can  you  draw  from  the  personnel  inputs? 

The  engineer  will  then  proceed  to  develop  the  two  flow  diagrams 
At  the  conclusion  of  the  session  he  is  told  (both  experimental  and  control 
subjects):  Now  that  you  have  completed  your  task,  I  would  like  to 
review  your  diagrams  with  you.  Specifically,  I  want  to  know  why  you 
included  the  particular  functions  you  did,  and  whether  any  information 
you  received  at  the  start  of  the  session  suggested  the  functions  you 
listed.  I  also  want  to  know  why  you  allocated  certain  functions  to 
equipment  and  others  to  personnel. 

At  the  conclusion  of  the  session,  the  experimenter  will  retrieve 
the  diagrams  the  engineer  has  developed  and  give  him  the  next  session's 
inputs.  A  xerox  copy  of  his  diagrams  will  be  made,  and  they  will  be 
returned  to  him  on  the  siwe  day. 
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PERSOUEL  FUMCTICB/TASK  rWMB4A.TIC3ll 
Transfer  Fuel  from  H?  car  to  R5Y 

1.  Find  and  connect  the  appropriate  flex  hoses  fra  the  KB  car 
to  the  storage  tank. 

2.  Open  fill  valve  on  HK  car  and  storage  tank. 

3.  Open  vent  valves  on  storage  tank. 

k.  Initiate  fuel  transfer. 

5.  Monitor  aaoimt  of  fuel  being  transferred. 

6.  Close  storage  tank  and  KR  car  fill  valves. 

7.  Disconnect  f1  ex  hoses  from  storage  tank. 

8.  Monitor  fuel  teoperature. 

9.  Adjust  fuel  temperature. 

Transfer  Fuel  from  RSV  to  SLY  Tanks 

l.  Connect  PEPS  umbilxcals  to  missile  tanks. 

2.  Open  rocket  tank  fill  and.  vent  valves. 

3.  Open  storage  tank  fill  and  vest  wives. 

1,.  Determine  that  fill  and  vent  valves  are  open,  drain  valves 
closed. 

5.  Initiate  pressurization  of  PH’S. 

6.  Signal  return  of  all  personnel  from  the  laun  :h  area. 

7.  Initiate  filling  of  PEPS. 

8.  Determine  that  fuel  has  beg,m  to  flow. 

9.  Monitor  fuel  flew  and  amount. 

10.  Regulate  aaouit  of  fuel  being  transferred. 

11.  Check  fuel  temperature  and  adjust. 
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Determine  that  rocket  tankr  are  filled  to  the  proper  aaount 
Stop  transfer  of  fuel. 

Close  storage  tank  fill  valves. 

Drain  and  close  FTPS  fill  lines. 

Close  rocket  tank  fill  and  vent  valves. 


SESSION  2 


Instructions  To  Participating  Engineers 

In  this  session,  we  ask  you  to  imagine  that  a  period  of  time 
in  the  development  of  the  PTPS  has  elapsed  and  that  consequently 
additional  information,  gathered  by  other  members  of  the  project  team, 
is  available  concerning  PTPS  functions.  This  information  la  presented 
in  two  forms,  a  partially  completed  Requirements  Allocation  Sheet  (RAS) 
and  a  more  detailed  functional  flow  diagram  of  personnel  operations 
H^«ures~~5  and  f  ) .  On  the  RAS  the  following  ls~  available: 

1.  Major  subfunctions  (Function  Name  and  No.  Column); 

2.  Initial  design  requirements  for  these  sub functions 
(Design  Requirements  Column); 

3*  Personnel  tasks  which  must  be  performed  to  accomplish 
these  subfunctions  (Tasks  Column)"; 

4.  Performance  requirements  to  accomplish  these  personnel 
tasks  (Performance  Requirements  Column)" 

The  flow  diagram  of  personnel  operations  corresponds  to  the  tasks 
listed  on  the  RAS. 

Your  job  in  this  session  is  to  take  the  initial  design  requirements 
together  with  th<>  other  information  available  to  you  (including 
information  from  the  preceding  session)  and  describe  the  characteristics 
of  the  equipment  needed  to  accomplish  the  design  requirements.  We 
would  like  you  to  describe  in  as  much  detail  as  possible  the  following: 

1.  The  nature  of  the  components  required  (e.g.,  motors,  valving, 
piping,  pumps,  etc.) 

2.  How  this  equipment  would  operate  to  perform  its  functions 

3.  Function  limitations  and  tolerances 

4.  How  the  equipment  ties  in  with  other  equipments  and  functions 

5.  The  physical  facilities  (e.g.,  geographic  layout)  you  would 
need  to  have  to  implement  the  design  requirements. 

Indicate  only  general  dimensions,  without  worrying  about  precise 
tolerances. 
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Personnel  Operations  Flow  Dlecraa 


Before  you  go  ahead,  however,  but  after  you  review  this  material, 

I  would  like  to  ask  a  few  questions: 

1.  Do  you  have  enough  information  to  describe  the  equipment  you 
need  to  accomplish  these  functions? 

2.  If  not,  what  is  lacking?  What  information  would  you  like 
to  have?  What  information  would  you  expect  to  have? 

3.  Is  there  too  much  informal  '  for  this  stage  of  system 
development? 

k.  What  information  about  personnel  functions  and  tasks  would 
you  wish  to  have  to  perform  your  task  in  this  session? 

! ?.  What  personnel  information  would  you  ordinarily  have  r_t  this 

stage  of  system  development?  Is  this  information  sufficient? 

6.  If  the  number  of  men  needed  to  operate  and  maintain  the  PTPS 
and  their  skill  levels  were  available  now,  would  it  help  you  in  describ¬ 
ing  the  required  equipment?  If  so,  how? 

The  following  questions  are  asked  only  of  the  experimental  subjects: 

l.  Do  you  find  the  information  on  personnel  tasks  and  performance 
requirements  on  your  RAS  sheet  useful  in  performing  today's  task? 

2.  Would  you  ordinarily  expect  to  receive  information  of  this 
sort  at  this  stage  of  system  design?  Would  you  generate  thi6  informa¬ 
tion  yourself?  Is  this  information  too  early,  too  late  or  just  in  time? 

3.  Do  you  understand  the  personnel  information?  If  not,  what  do 
you  not  understand? 

U.  Is  the  performance  requirements  information  on  the  RAS  more, 
or  less  or  equally  useful  as  the  information  under  the  task  column? 

5.  Which  version  of  the  personnel  task  information  do  you  find 
more  useful,  the  flow  dxagram  or  the  RAS  material? 

6.  Can  you  apply  the  personnel  information  to  your  analysis  of 
equipment  requirements? 

* 

7.  What  equipment  design  implications  can  you  draw  from  the 
personnel  information? 

^Procedures  for  debriefing  at  the  conclusion  of  the  session 
the  same  as  in  Session  1^ 
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Instructions  To  Participating  Engineers 

In  thi6  session  additional  information  is  available  to  you  concern¬ 
ing  the  primary  functions  which  the  PTPS  oust  perform. 

The  information  consists  of  more  detailed  design  requirements  and 
equipment  characteristics  than  was  available  previously.  In  addition, 
an  analysis  has  been  made  by  the  Human  Factors  section  of  the  control/ 
display  equipment  which  the  PTPS  system  will  require.  (Not  given  to 
control  subjects/j  Naturally  you  may  use  all  your  previous  information. 

What  we  want  you  to  do  in  this  session  is  to  review  and  amplify 
your  previous  equipment  descriptions  ir  the  light  of  the  new  information. 

In  addition  we  would  like  you  to  develop  a  set  of  equipment  flow  diagrams 
which  describe  in  as  much  detail  as  you  can  how  the  equipment  operates. 

Before  you  go  ahead,  however,  I  should  like  to  ask  a  few  questions 
with  reference  to  the  new  information  provided  in  this  session: 

1.  Do  the  new  inputs  provide  you  with  enough  information  to 
describe  the  equipment  you  need  in  as  much  detail  as  you  would  wish? 

2.  What  additional  information  would  you  like  to  have?  Of  what 
type?  What  additional  information  would  you  expect  to  receive? 

3-  What  information  about  personnel  activities  would  you  wish  to 
have  to  make  up  your  equipment  flow  diagram? 

b.  What  personnel  information  would  you  ordinarily  have  at  this 
stage  of  system  development?  Is  this  Information  sufficient? 

5.  If  the  number  of  men  needed  to  operate  and  maintain  the  FTPS 
and  their  skill  levels  were  available  now,  would  It  help  you  in  develop¬ 
ing  the  equipment  flow  diagrams?  If  so,  how? 

Ihe  following  questions  are  asked  only  of  the  experimental  group: 

6.  Do  you  find  ohe  memorandum  on  control/di splay  requirements 
useful  in  performing  today's  task? 

7.  Would  you  ordinarily  expect  to  receive  information  of  this 
sort  at  this  stage  of  system  design?  Would  you  generate  this  information 
yourself?  Is  this  information  too  early,  too  late,  or  just  in  time? 

6.  Is  the  information  sufficiently  precise  and  detailed;  too  general? 
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9.  Can  you  apply  this  information  to  your  analysis  of  equipment 
requirements? 

10.  What  equipment  design  implications  can  you  draw  from  the 
memorandum? 

11.  Do  you  agree  or  disagree  with  the  recommendations  made  in  tne 
memorandum? 

As  in  previous  sessions,  a  review  of  the  engineer's  design  outputs 
will  be  performed  at  the  close  of  the  session. 


Supplementary  Information  To  Be  Added  To 
Requirements  Allocation  Sheets  After  Approval 


Pune t i on :  Transfer  Liquid  Propellants  to  Ready  Storage  Area 

A  requirement  exists  to  transfer  Titan  X  SLV  liquid  propellants  from 
the  Propellant  Tanjc  Car  Storage  Area  or  a  Bulk  Storage  Area  tc  ready 
storage  areas  at  launch  Complex  40. 

The  Titan  X  SLV  liquid  propellants  are: 

A.  Hydrazine/unsynmetrf  cal-Dimethylhydrazine  (50^2^4  "  50y  UEMH)  , 
which  hereafter  will  be  referred  to  as  fuel.  Reference  is 
made  to  MIL-P-27402  (USAp),  25  August  15517 

B.  Nitrogen  Tetroxide  (^0^),  which  hereafter  will  be  referred 
to  as  oxidizer.  Reference  is  made  to  MIL-P-26539A,  31  July 
1961. 

The  maximum  amount  of  fuel  required  in  the  fuel,  holding  area  at 
any  one  time  is  22,000  gallons.  The  maximum  amount  of  oxidizer  required 
in  the  oxidizer  holding  area  at  any  one  time  is  28,000  gallons. 

The  fuel  and  oxidizer  must  be  transported  to  separate  ready  storage 
areas  by  either  railroad  tank  cars  or  road  tank  trailers. 

A.  Railroad  tank  cars  will  be  the  primary  mode  of  transportation. 

The  fuel  holding  area  must  be  separated  from  the  oxidizer  holding 
area  by  a  miniifum  of  700  feet 

It  is  anticipated  that  fuel  will  be  delivered  in  railroad  tark  cars 
similar  to  Model  ICC  103C-W  which  has  an  approximate  capacity  of  7,500 
gallons . 


B.  Provisions  must  be  made  to  obtain  personnel  access  to  the 
dome  housing  on  each  railroad  tank  car. 

Platforms,  ladders  and  handrails  must  be  provided  to  vain  access 
to  the  dome  housiug  on  each  railroad  tank  car.  Walkways  for  each  tank 
car  must  be  constructed  so  that  they  can  be  ’•©red  Dui  cf  the  way  for 
tank  car  movements. 

The  hazards  (toxic,  fire,  corrosive)  presented  by  each  of  the 
propellants  require  preparatory  tacks  and  functions.  These  must  be 
accomplished  prior  to  the  time  either  cf  the  two  p re; ell  nts  ore,  by 
any  means,  removed  from  a  tank  car.  It  is  required  to  validate  all 
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supporting  tasks  and  functions  necessary  to  the  actual  transfer  of 
propellants  as  follows: 

A.  Safety  regulations  and  procedures  for  the  handling  of  liquid 
propellants  shall  be  provided  and  strictly  enforced  in  accord¬ 
ance  with  the  following  document  and  applicable  waivers: 

1.  AFTO  11C -1-6  General  Safety  Precautions  for  Missile 
Liquid  Propellants,  dated  27  November  19^1 ,  latest 
revision. 

B.  Criteria  for  the  protection  of  personnel  have  been  established 
for  all  functions  performed  during  transfer  of  propellants. 

1.  Conqslete  protective  clothing  and  the  conditions  under 
which  it  will  be  used. 

2.  Partial  protective  clothing  and  the  conditions  under 
which  it  will  be  used. 

3.  Portable  toxic  vapor  detectors  which  are  used  to  sense 
the  quantity  of  UDMH  and  NOg  vapor  in  the  atmosphere. 

C.  In  order  to  accomplish  the  propellant  transfer  operations,  the 
following  communication  systems  must  be  provided: 

1.  Dial  telephone 

2.  Public  address 

3.  MITOC  (Missile  Technical  Operations  Communication) 

D.  A  hazard  warning  system  must  be  provided  to  alert  personnel 
to  the  presence  of  propellants  on  the  launch  complex. 

The  existing  requirement  to  transfer  propellants  to  ready  storage 
vessels  must  be  accomplished  by  utilizing  a  nortion  of  the  propellant 
(fuel  and  oxidizer)  transfer  system. 

That  portion  of  the  PIPS  that  will  be  used  for  transfer  consists  of 
fluid  equipment  end  items,  components,  instruments,  and  connecting  piping 
that  together  enable  propellants  to  be  received  from  delivery  vehicles 
and  stored. 

The  requirements  for  the  portion  of  the  propellant  transfer  system 
to  be  utilized  for  this  function  are  as  follows: 
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The  equipment  end  items  ( ready  storage  vessel( 6)  and  propellant 
loading  units) ,  fixed  piping  and  components  all  of  which  are 
located  in  the  holding  areas  will  be  utilized, 

A  requirement  exists  for  a  centred  control,  and  distribution 
unit  for  the  transfer  operation. 

The  central  control  area  should  contain  centrifugal  pumps, 
totalizing  flowmeters  in  series,  an  automatic  flow  control 
system,  associated  valves,  monitors,  and  controls  necessary 
to  perform  the  transfer  function. 

1.  Propellant  shall  be  pumped  from  the  delivery  vehicle 
into  the  storage  ve3sel(  s)  where  it  is  stored,  bypassing 
the  flow  measurement  subsystem  if  desired.  Pump  shall 
operate  up  to  a  maximum  flow  rate  of  200  GPM. 

A  nominal  transfer  rate  of  100  GPM  is  selected  as  time 
is  not  a  prime  consideration  during  this  period  and 
increased  reliability  of  equipment  should  result. 

2.  Provide  pressurization  of  the  delivery  vehicles  to 
satisfy  the  pump  NPSH  requirements.  The  NPSH  require¬ 
ments  shall  be  based  on  the  propellants  being  pumped 
between  plus  4-5°F  and  plus  90°*’-  The  delivery  vehicles 
shall  be  so  positioned  that  propellant  can  be  pressure 
transferred  to  the  FLU  (Propellant  Loading  Unit).  In 
order  to  prime  the  pump  (PUl)  the  approximate  GN2 
pressure  to  the  delivery  vehicle  shell  be  as  follows: 

(1)  Fuel:  20  psig  to  trailers 

30  psig  to  tank  cars 

(2)  Oxidizer:  40  psig  to  trailers 

50  psig  to  tank  cars 

The  purge  and  vent  subsystem  within  the  PLU  that  will  be  used 
shall  consist  of  control  valves,  piping,  and  back  pressure 
regulators  that  enable  "closed  or  open  loop"  transfer.  The 
same  piping  arrangement  shall  also  provide  the  capability 
of  blanketing  and  purging  the  transfer  system. 

The  nitrogen  subsystem  within  the  PLU  that  will  be  used  shall 
consist  of  pressure  regulating  valves,  control  valves, 
instrumentation ,  ard  associated  piping  to  meet  the  transfer 
requirements.  The  subsystem  shall  reduce  nitrogen  gas 
supply  from  150  psig  to  pressures  required  for  the  following 
uses  at  supply  flows  up  to  0.5  lb. /sec: 


1.  Blanket,  pressures  for  fuels: 


7.2  to  12  psig 
for  oxidizer: 

7.2  to  23  psig 

2.  Pressurization:  20  to  50  psig 

3.  Purge:  20  to  30  psig 

single-spaced  pages  of  equipment  information  were  also  provid-'dfj 
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Control-Display  Recomm endations 


lb:  Project  Engineer,  PTJS  Project 

Fran:  Hvan  Factors  Section,  Personnel  Subsystem  Group 

SuD j . :  Control -1'ispxay  i?-c  emendations  resulting  from 

Htann  Factors  Ana Zja  i 


The  following  represents  our  analysis  of  control-display  require¬ 
ments  based  o»  the  limited  amount  of  information  available  to  date. 

1.  Open  and  closed  Indications  should  be  provided  for  all  fill  and 
drain  valves  in  piping  leading  to  Stage  I  and  II  missile  propellant 
tanks,  as  well  as  for  their  respective  vent  valves.  Die  same  recom¬ 
mendation  can  be  made  for  the  bleed  valves  for  both  Stage  I  and  II  fill 
lines.  Since  these  valves  may  have  to  be  operated  remotely,  (once 
propellant  is  in  the  lines),  the  use  of  illuminated  (for  display) 
pushbuttons  should  be  considered.  Valves  which  are  never  operated 
remotely  should  not  be  displayed.  Die  indications  provided  should 
display  the  actual  position  of  the  valve,  not  merely  the  fact  that 
electrical  energy  has  been  supplied  to  the  line  leading  to  the  valve 
(which  has  often  been  the  case). 

One  of  the  problems  involved  in  displaying  valve  positions  is  that 
in  different  operating  sequences  certain  valves  should  be  open  while 
others  are  closed.  It  would  therefore  be  necessary  not  only  to  indicate 
the  actual  position  of  the  valve  but  also  the  position  the  valve  should 
be  in  for  that  sequence.  Consideration  should  also  be  given  to  arrang¬ 
ing  the  valve  displays  in  a  schematic  of  the  POPS  system.  This  might 
assist  personnel  in  understanding  the  functional  interrelationships  of 
the  valves. 

2.  Pressure  indications  should  also  be  provided  for  Stqge  I  and  II 
missile  tanks,  as  well  as  coatrols  for  pressurizing  these  tanks. 

3.  Controls  should  be  provided  to  turn  the  unit  supplying  the  nitrogen 
gas  uadLer  pressure  on  and  off.  Pressure  indications  will  also  be  needed 
for  the  RSV  as  well  as  for  the  fuel  transport  vehicle. 

4.  Controls  for  initiating  .  rd  stopping  fuel  flew  are  required;  also 
to  control  blanket  pressure  within  the  PTPS  lines.  A  meter  is  required 
for  displaying  ibe  flow  of  fuel.  Digital  ccjnters  should  be  made  avail¬ 
able  for  determining  the  amount  of  fuel  actually  being  tanked.  This 
will  involve  a  linkage  with  sensors  located  In  the  missile  propellant 
tanks. 


5*  The  temperature  of  the  fuel  at  each  place  in  which  it  is  sensed 
should  be  displayed.  Consideration  should  be  given  to  whether  all 
locations  should  be  recorded  simultaneously,  or  successively,  and  whether 
the  precise  temperature  should  be  indicated  or  simply  an  indication  of 
over  or  under  temperature. 

6.  All  hoses  requiring  manual  connection  should  be  color  coded  or 
otherwise  marked  to  make  their  identification  easy  or  their  connections 
(pins)  so  coded  as  to  make  cross  or  incorrect  connection  of  hoses 
impossible. 

7.  Consideration  should  be  given  to  the  centralization  of  all  the 
control/display  functions  listed  above  within  a  single  station  or  console. 
If  such  a  central  station  were  established,  consideration  should  also 

be  given  to  providing  a  means  of  automatically  checking  out  the  PUS 
from  that  station.  Such  a  checkout  facility  might  Include  the  capability 
of  isolating  Pl!Rs  malfunctions  to  individual  valve  or  other  major 
components . 

Should  a  central  control  station  be  established,  consideration 
should  also  be  given  to  having  redundant  and  parallel  controls  and 
displays  for  each  of  the  various  operational/maintenance  sequences. 

Urns,  the  station  might  consist  of  a  section  for  transferring  fuel  from 
the  transporter  to  the  RSV,  a  section  for  fuel  transfer  to  the  SLV,  and 
one  for  maintenance/malfunction  identification.  Similar  sections  for 
the  oxidizer  side  of  the  PEPS  would  also  be  required.  Certain  controls 
and  displays  required  for  transferring  fuel  from  the  transporter  to 
the  RSV  may  have  to  be  included  on  the  transporter  itself.  Under  those 
circumstances  it  would  be  necessary  to  devise  same  means  of  integrating 
centralized  control  functions  with  those  of  the  transporter. 

8.  Your  comments  with  regard  to  the  recoMendatians  made  in  this 
memorandum  would  be  greatly  appreciated. 
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SESSION  4 


Instructions  For  Participating  Engineers 

Information  supplementing  what  you  have  been  given  previously 
concerning  the  equipment  characteristics  of  the  PIPS  has  become  avail¬ 
able.  In  addition,  the  Personnel  Subsystem  Group  has  provided  a  pre¬ 
liminary  task  analysis  of  PTFS  operations.  [[Control  subjects  do  not 
receive  the  task  analysis.] 

In  this  session  we  will  ask  you  to  review  both  of  these  inputs  and, 
keeping  in  mind  also  the  information  you  have  received  previously, 
we  want  you  to  develop  a  list  of  the  control-display  hardware  required 
to  operate  the  PTPS.  Your  list  should  describe  the  following  parameters: 

1.  Nature  of  the  control  or  display  (e.g.,  gage,  indicator, 
lever,  etc.); 

2.  Any  alternative  control  or  display  you  can  think  of; 

3.  The  function  to  be  performed  by  the  device; 

4.  Any  characteristic  of  the  device  that  you  can  think  of; 

5.  Where  the  control  or  display  should  be  located; 

6.  The  reason  for  the  control  or  display. 

In  reviewing  the  material  available  to  you,  we  should  also  like 
you  to  <-hink  a  little  about  the  number  and  type  of  men  you  would  need 
to  operate  and  maintain  the  PiPS.  By  type  of  men  we  mean  their  training, 
experience  and  skill  level.  We  will  ask  you  about  this  at  the  conclusion 
of  the  session. 

Before  you  go  ahead  to  make  up  your  list,  however,  I  would  like 
to  ask  a  few  questions: 

1.  I)o  you  now  have  enough  information  to  list  the  control-display 
hardware  vou  would  ne'xl  to  accomplish  PTPS  functions?  Subsequent 
questions  are  essentially  the  same  as  in  previous  sessions. 

The  following  questions  are  asked  only  of  experimental  subjects: 

1.  Do  you  find  the  preliminary  task  analysis  from  the  Personnel 
Subsystem  Group  useful  in  performing  today's  task? 


2.  Would  you  ordinrrily  expect  to  receive  information  of  this  sort 
and  to  tills  level  of  detail  at  this  stage  of  system  development?  Would 
you  generate  this  information  yourself? 

3*  Do  you  have  any  difficulty  in  understanding  the  task  analysis? 
If  so,  what  aspect  of  it  gives  you  difficulty? 

Take  up  each  part  of  the  task  analysis  separately  and  ask  about  the 
engineer's  understanding  of  that  part. 

4.  Does  the  time  information  have  any  design  implications  for  you? 
Does  it  help  with  the  list  of  control-display  hardware? 

5.  Does  the  performance  requirements  information  have  any  design 
implications  for  you?  Does  it  help  with  the  list  of  control-display 
hardware? 


6.  How  about  the  performance  probability  figures?  Can  you  interpret 
them  in  terms  of  the  design  of  the  PTPS? 

7.  How  about  the  difficulty  index? 

8.  How  well  do  you  feel  you  know  what  the  PTPS  personnel  should 
do  in  operating  the  system?  Have  any  of  the  personnel  inputs  to  date 
helped  to  give  you  a  better  understanding  of  these  operations? 

9.  As  between  a  task  which  is  single  and  one  which  is  complex, 
what  design  differences  would  you  incorporate?  What  would  you  do  to 
make  the  conplex  task  simpler? 


Additional  Supplementary  Information 


Prove r  Loop 

Due  to  the  ij^portaoce  of  an  accurate  SLV  propellant  load , 
the  flowmeter  circuit  should  be  verified  before  the  alSBile  is  loaded. 
Ibis  verification  circuit  ’./ill  Include  a  calibrated  prove r  tank  of 
100  gal loos  and  two  level  sensing  devices,  one  installed 

at  the  bottom  and  one  in  tailed  at  the  top  of  the  p rover  tank.  Pro¬ 
pellant  flow  is  directed  into  the  tank  from  the  bottom.  When  liquid 
contacts  the  bottom  liquid  sensor,  the  flow  totalizer  stops.  he  flow 
measuring  system  is  verified,  by  catering  the  totalizer  number  with 
the  known  volume  of  the  prover  tank. 

The  p rover  tank,  will  be  calibrated  to  100  gallons  ♦  .05^  by  volume. 
A  full  leugth  sight  glass  should  show  liquid  level  just  above  the  top 
sensor  and  indicate  the  empty  condition  after  drainage. 

Flow  Control  Value 

A  flow  control  valve  (KTV-l)  will  control  projjellant  flow 
rates  within  the  transfer  system.  It  is  comally  closed  and  moves  to 
the  full  open  position  with  the  application  of  supply  pressure  (60  PSl) 
and  a  15  B3I  instrument  M2  signal .  The  supply  pressure  is  controlled 
by  a  3~way  solenoid  valve.  The  instrument  Ip  signal  is  supplied  by  the 
recorder  controller.  The  position  of  the  valve  is  proportional  to  the 
3-15  PSI  instrument  signal. 

Check  Valve  FL-FFUJ-CHV-1 


Downstream  cl  the  FCV  a  check  valve  will  be  provided.  This 
1  1  mqiuiH  11 1  is  placed  here  to  prevent  back  flow  through  the  system.  It 
is  a  swing  type  check  valve  which  opens  with  1-9  PSX  or  less.  It  is 
made  of  stainless  steel  with  seals  of  virgin  unplasticized  teflon. 

(fcilck  Disconnects 

The  quick  disconnect  couq*Xing(&)  will  consist  of  an  airborne 
half  and  a  ground  half..  The  coupling  is  used  during  the  filling  of  the 
vehicle  propellant  tanks  frcta  the  ground  propellant  supply,  draining 
vehicle  tanks  into  toe  ground  system,  venting  nitrogen  gas  and  propellant 
vapors  from  the  vehicle  tanks  into  the  vent  system,  etc. 


it  all,  7  single-spaced  pagee  of  supplementary  equipment  details 
were  provided 3 
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Preliminary  Ta&k  Anajjais 


Tb:  Project  Baglneer,  POTS  Project  _ ,  1967 

Proa:  Peruoonel  Subsystem  Group 

SubJ:  Preliminary  Task  Analysis  of  POTS  Operations 


The  following  is  an  Initial  analysis  of  POTS  operations  in  terns 
of  the  personnel  performance  requirements  (including  task  complexity 
and  safety  provisions),  the  estimated  length  of  time  inquired  or  the 
operation  and  the  probability  that  the  operation  will  be  performed 
correctly.  A  difficulty  index  1b  also  provided. 

The  following  should  be  noted.  A  blank  in  the  time  column  indicates 
that  the  time  will  be  variable,  depending  an  individual  operational 
candl  tlans . 

The  performance  probability  Indicates  the  percentage  probability 
that,  if  the  task  were  repeated  over  10,000  operating  cycles,  the  task 
would  be  performed  correctly.  Jtor  example,  if  the  probability  is  .999t>> 
this  would  mean  that  one  would  expect  the  operator  to  mmke  an  error  only 
5  times  out  of  10,000.  .Tn  skill  equivalents,  these  probability  values 
mean  the  following: 

•9900  -  -9999  =  extremely  simple  task  requiring  Little  skill. 

•9000  -  .9689  -  moderately  precise  task  requiring  some  trailing 
and.  a  fair  degzee  of  experience. 

.9500  -  .9779  *  highly  precise  task  requiring  Judgment*  a  good 
deal  of  training  and  extensive  experience. 

Difficulty  Index 

1.  level  1  Involves  simple  manual  operations  like  throwing  a 
switch  or  pushing  a  button;  or  simple  recognition  of  go- no  go  indications. 
The  operation  nay  be  performed  by  a  skilled  operator  without  »  checklist 
or  by  a  novice  with  a  checklist.  Guly  simple  Judgment  would  be  required. 
The  information  needed  to  perform  the  operation  would  be  limited  to 
direct  recall  of  simple  facts  involved  in  recognition  of  device-  -  and 
their  general  function.  Rrtnemcly  low  human  error  potential:  for 
experienced  personnel,  .001$;  for  inexperienced  personnel  (although 
trained) ,  .01$. 
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2.  Level  2  involves  moderately  precise  manual  operations  such  as 
adjusting  a  potentiometer  or  torquelng  a  wrench  to  a  predetermined  value. 
From  a  visual  standpoint  it  might  involve  reading  a  quantitative  meter 
or  interpolating  a  scale  value.  The  operation  might  involve  the  coordin¬ 
ation  of  a  manual  action  with  a  visual  one,  whereas  level  1  would  not. 

A  moderate  degree  of  Judgment  would  be  required,  ouch  as  that  involved 
in  estimating  how  long  an  action  should  be  performed,  performing  a 
visual  check,  or  making  decisions  based  on  information  from  several 
sources.  The  information  needed  tc  perform  the  operation  might  involve 
the  principles  of  system  operation,  e.g.,  knowing  the  effects  of  activating 
a  control  on  downstream  valves.  There  is  moderate  error  probability 
for  experienced  personnel,  .01$;  for  inexperienced  personnel,  5$. 

3.  Level  3  Involves  very  precise,  complex  manual  operations  such 
as  those  involved  in  removing  or  replacing  delicate  components.  It  may 
involve  a  high  degree  of  perceptual  precision,  such  as  reading  frequency 
waves  or  discriminating  slight  differences  in  shades  of  the  same  color 
(e.g-,  determining  corrosion).  A  considerable  amount  of  decision-making 
Judgment  is  required  as  in  troubleshooting  a  failed  device  or  in  coordin¬ 
ating  the  actions  of  a  number  of  personnel  in  the  same  system  operation. 

The  information  needed  to  perform  the  operation  would  involve  the  organiza¬ 
tion  of  many  highly  detailed  facts  derived  from  memory  and  deduction 

of  their  implications  for  action.  There  is  an  extremely  high  human 
error  potential  for  inexperienced  personnel,  e.g.,  50-75$.  For  exper¬ 
ienced  personnel  the  error  probability  is  about  10-20$. 
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8.1  Open  RSV  fill  valve  2  Simple  manual  task  .9978 

J3  Additional  Pages  of  Task  Analysis  Material  Were  ProvidedT] 


SESSION  5 


Instructions  To  Participating  Engineers 


In  this  session  I  will  ask  you  to  consider  the  preventive  mainten¬ 
ance  requirements  of  the  PTPS.  These  are  liBted  on  your  new  RAS  sheet. 

( Figure  8  ) . 

The  following  general  information  concerning  preventive  maintenance 
is  available: 

1.  Organizational  maintenance  of  the  propellant  transfer  system 
consists  of  periodic  visual  inspection  of  all  piping  systems  including 
valves ,  controls  and  instrumentation]  operating  the  pumps  for  a  short 
period  of  time  and  lubrication  if  necessary;  and  inspection  and  cleaning 
of  filter  elements. 

2.  Field  maintenance  includes  replacing  or  repairing  defective 
lines,  valves,  hoses,  pumps,  motors,  controls,  and  refastening  of  loose 
piping  and  equipment. 

3.  Depot  maintenance  will  include  major  repairs  to  pumps,  motors, 
and  other  machinery  as  well  as  major  repairs  to  controls  and  instrumen¬ 
tation. 

Notice  that  these  functions  involve  the  whole  range  of  preventive 
maintenance  functions:  calibration,  inspection,  verification  of  accuracy, 
checkout  and  lubrication. 

Under  the  personnel  section  of  the  RAS  we  have  listed  the  major 
tasks  to  be  performed  by  personnel  maintaining  the  PTPS. 

You  will  be  asked  to  do  two  things  in  this  session:  (l)  make  a 
functional  flow  diagram  of  the  functions  involved  in  performing  preventive 
maintenance;  (2)  describe  all  the  design  features  you  might  provide 
to  aid  the  maintenance  personnel  in  performing  these  activities.  These 
features  should  include: 

a.  required  controls  and  displays; 

b.  special  test  and  calibration  on  tools  and  equipment; 

c.  access  spaces; 

d.  test  points: 

f .  connections; 
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f.  safety  provisions,  etc. 


Here  Is  a  checklist  which  might  help  you  to  remember  features 
you  may  wish  to  incorporate  in  your  design  characteristics.  If  you 
can  think  of  a  more  effective  way  of  performing  the  maintenance  functions, 
list  any  changes  you  would  make.  Add  any  maintenance  tasks  which  you 
feel  would  be  required  or  be  desirable,  even  if  not  listed  on  the  RAS. 
Remember  the  type  of  maintenance  man  who  will  be  provided  to  do  these  jobs. 

Before  you  go  ahead,  however,  I  would  like  the  answers  to  a  number 
of  questions: 

1.  Do  you  have  enough  information  to  do  what  you  have  been  asked 
to  do? 

2.  If  not,  what  is  lacking?  What  information  wouM  you  like  to 
have?  What  information  would  you  expect  to  have? 

3.  Is  the  information  provided  on  the  RAS  sheets  useful  in  perform¬ 
ing  the  task? 

4.  Would  you  ordinarily  expect  to  receive  information  of  this  type 
at  this  stage  of  system  development?  From  whom?  Would  you  generate 

the  information  yourself?  How? 

5.  Does  the  checklist  assist  in  any  way? 

6.  If  you  knew  the  number  and  type  of  maintenance  men  you  were 
going  to  have,  would  this  help  you  in  performing  the  task? 

The  following  questions  are  asked  only  of  experimental  subjects: 

1.  Do  you  find  the  information  on  your  RAS  sheets  under  Tasks 
useful  in  performing  the  task?  Task  information  was  not  provided  to 
control  subjects. 

2.  Can  you  apply  that  information  to  today’s  task? 

3.  What  equipment  design  Implications  can  you  draw  from  this 
personnel  information? 

4.  Would  you  ordinarily  expect  to  receive  this  personnel  informa¬ 
tion  at  this  stage  of  system  design?  Earlier?  Later? 
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MAJNTAINAB ILI TI  CHECKLIST 


GENERAL 

1.  Standardization  maximized  8.  Labeling  maximized 

2.  Components  functionally  grouped  9*  Weight  minimized 

3.  Console  layout  optimized  10.  Calibration  requirements  known 

4.  Complexity  minimized  11.  Re pair/ replace  philosophy  known 

Self- test  incorporated  12.  Maint.  procedures  known 

6.  lfex.  time  to  repair  minimized  13-  Personnel  requirements  minimized 

7--  Tools  St  test  equip,  minimized  14.  Trade-offs  documented 


HAHDLIHG 

1.  Equipment  lifting  means 
employed 

2.  Equipment  base  reinforced 
(fork-lift  app.) 

3.  Drawer  St  panel  handles 
employed 

4.  Assembly  handles  employed 

5.  Console  castors  employed 
(as  applicable) 

6.  Damage  susceptibility  minimized 

7.  Weight  label  on  console 


..T — ■  .  — ■  —  ... 

1.  Drawers  on  roll-out  slides 

2.  Panels  hinged 

3.  In-position  maintenance 
possible 

4.  Cables  connected  vith  drawers 
extended 

5.  Permanent  cable  inlets  on  front 
avoided 

6.  Heaviest  items  on  bottom 

7.  Operator  panels  option* 
position 

8.  Air  intake  A  exhaust  prv  v- 
islons  adequate 


PANEL  hlbFIAYS/ CONTROLS 

1.  Controls  standardized 

2.  Controls  sequentially  positioned 

3.  Controls  properly  spaced 

4.  Controls  adequately  labeled 

5.  Controls  adjacent  to  applicable  display 

6.  Rugged! zed  meters  employed 

7.  Meters  externally  removable 

8.  Panel  lighting  employed 

9-  Indicator  lights  "press-to-test" 

10.  Fuse  requirements  satisfied 

11.  Spare  fuses  provided 

12.  Warning  lights  employed-critical 
functions 

13-  Color  of  indicator  lights  adequate 
14.  Controls  placed  by  frequency  of  use 

TEST  POINTS 

1.  Located  on  front  panel 

2.  Functionally  grouped 

3.  Adequately  labeled-number  &  signal 
value 

4.  Internal  test  points  accessible 

5.  Degree  of  test  indicated 

6.  Adequately  protected 
7-  Adequately  illuminated 

8.  Located  close  to  applicable  control 


PACKAGING  ADJUSTMENTS 

1.  Plug-  in  coaqponents  employed  1.  Adjustment  points  accessible 

2.  Component  stacking  avoided  2.  Periodic  adjustments  known 

3.  Accessibility  based  on  3-  Interaction  effects  eliminated 

replacement  freq.  4.  Adjustment  locking  devices  provided 

4.  Wrong  installation  of  unit  5.  Factory  adjustments  specified 

prevented  6.  Adjustment  points  adequately  labeled 

5.  Modules  A  mounting  plates  f .  Fine  adjustments  through  large 

labeled  movements 

6.  Guides  used  for  module  Install-  3.  Built-in  jacks  for  meter  calibration 

ation  9.  Clockwise  adjustments  for  ir.c r»'-ring 

7.  Interchangeability  incorporated  values 
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PARTS/ COMPONENTS 

1.  Arranged  in  family  groups 

2.  Adequately  labeled 

3.  Adequately  spaced  for  tool  access 

4.  Individual  parts  directly  accessible 

5.  Delicate  parts  adequately  protected 

6.  Not  vulnerable  to  excessive  solder 
heat 

FASTENERS 

1.  Quick  release  fasteners  employed 

2.  Fasteners  standardized 

3.  Quantity  of  fasteners  minimized 

4.  Hexagonal  uocket-head  fasteners  used 

5.  Captive  nut  &  screws  employed 

6.  Minimum  number  of  turns  required 

CABLES 

1.  Cables  fabricated  in  removable 
sections 

2.  Cables  routed  to  avoid  sharp  bends 

3.  Cables  routed  to  avoid  pinching 

4.  Protection  for  cables  routed 
thru  holes 

5.  Cables  identified 

6.  Cable  clamping  support  adequate 

7.  Handhold  &  step  prevention 
considered 

CONNECTORS 

1.  Quick  disconnect  variety 

2.  Connector  spacing  adequate 

3.  Labeling  adequate 

4.  Connectors  keyed 

5.  Connec  ors  standardized 

6.  Spare  pins  provided 

7.  Male  connectors  capped 

8.  Receptaci  -  "hot”  &  plugs 
"cold" 

9.  Moisture  prevention  considered 


ACCESSIBILITY 

1.  Access  doors  provided 

2.  Access  doors  self- supported 

3.  Access  doors  labeled 

4.  Access  openings  adequate  in  size 

5.  Access  fasteners  minimized 

6.  Special  tools  minimized 

7.  Component  accessibility  adequate 

8.  Guides  for  dangerous  accesses 
considered 

SmRC«MEST 

1.  Temperature  &  humidity  ranges 
considered 

2.  Illumination  adequate 

3.  Transportability  conditions 
considered 

4.  Mobility  condi tions  considered 

5.  Storage  conditions  considered 

SAFETY 

1.  Electrical  outle La/ junction  boxes 
labeled 

2.  Interlocks  employed 

3.  Fuse  &  circuit  breaker  protection 
adequate 

4.  Warning  decals  adequate 

5.  Guards  &  safety  covers-higb 
potentials 

6.  Protruding  devices  eliminated 

7.  External  metal  parts  adequately 
grounded 

8.  Drawer/ panel/structure  edges 
rounded 

9-  Tool  use  considered 
RELIABILITY 

1.  Allocated  MTBF  known 

2.  Fail-safe  provisions  incorporated 

3.  Critieal/Bervice  life  considered 

4.  Wear-in/wear-out  cycles  considered 

5.  Failures  traceable  by  test 


When  reviewing  layouts/ drawings ,  this  checklist  may  prove  beneficial  in 
covering  various  design  features  applicable  to  maintainability.  The  Items 
or  categories  listed  are  in  most  cases  backed  up  with  more  detailed  questions 
baaed  on  specific  criteria.  The  list  is  so  designed  that  the  answer  to  each 
item  (as  applicable)  should  be  "yes’*. 

REFERENCE  DOCUMENTS  SPECIFYING  GOOD  MAINTAINABILITY  CRITERIA 

NAVJHIPS  9*3-’ 4,  Maintainability  Design  Criteria  Handbook  for  Designers 
of  Shipboard  Electronic  Equipment 

ASD-TR-61-424 ,  Guide  to  Integrated  System  Dr si  pi  for  Maintainability 
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SESSION  6A 


Instructions  For  Participating  Engineers 


In  this  session  no  further  equipment  inputs  are  available.  However, 
the  Personnel  Subsystem  Group  has  provided  two  (2)  time-line  analyses, 
one  for  operations,  one  for  preventive  maintenance,  for  the  two  major 
fueling  functions,  fuel  transfer  to  the  RSV,  and  fuel  transfer  from  , 

the  RSV  to  the  SLV.  [Control  subjects  did  not  receive  time-line  analyses. 
( Figures  8a  and  9A) . 

These  time  lines  analyses  represent  the  human  performance  require¬ 
ments  pertinent  to  the  PTPS .  Major  functions  are  described  in  terms 
of  the  time  required  to  perform  that  function  and  the  combination  of 
personnel  necessary  to  successfully  complete  the  functional  requirements 
of  the  system. 

Functions  are  listed  down  the  left  hand  column  vith  the  required 
personnel  indented  under  the  particular  function.  "Time  requirements 
for  the  particular  functions  are  repx-esented  incrementally  to  the  right 
of  the  task. 

Your  task  today  is  composed  of  several  parts: 

1.  Examine  the  time-line  analyses.  Note  that  they  give  you  the 
Personnel  Subsystem  Group's  concept  of  the  types  of  PTPS  personnel 
required  and  the  length  of  time  each  o *  their  tasks  should  take.  The 
time-line  analysis  can  also  be  interpreted  in  terms  of  the  number  of 
personnel  needed. 

2.  Using  this  Information  and  any  of  the  inputs  you  received 
previously,  indicate  how  many  control  and/or  display  panels  you  would 
need  to  operate  and  maintain  the  system.  A  panel  is  defined  as  any 
physical  space  specifically  designed  to  contain  two  or  more  controls 
or  displays.  Please  indicate  also  in  what  location  they  would  be 
found. 


3.  Indicate  the  operating  and  maintenance  functions  to  be  performed 
b v  each  control/ display  in  the  panel.  Provide  a  rough  layout  of  the  panel. 
(Definition  of  rough  layout  follows.]] 

In  addition,  wc  would  like  answers  to  the  following  questions: 

1.  Do  you.  have  enough  information  to  draw  rough  layouts  of  the 
control/display  panels? 
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2.  If  not,  what  information  should  you  have?  What  information 
would  you  realistically  viah  to  have? 

3.  What  information  about  personnel  operations  which  you  have 
not  received  In  previous  sessions  would  you  want  to  have? 

4.  What  previous  information  about  personnel  operations  is  relevant 
to  and  would  assist  in  your  laying  out  the  control/ display  panels? 


The  following  questions  are  asked  only  of  the  experimental  group: 

%  Do  you  have  any  difficulty  interpreting  the  time-line 
analyses? 

6.  If  so,  what  are  these  difficulties? 

7.  Does  the  tine- line  analysis  provide  you  with  any  information 
you  do  not  already  have? 

8.  Can  you  tell  me  in  a  few  words  what  information  the  time-line 
analysis  provides  you? 

9.  Do  you  agree  with  the  personnel  types  and  time  requirements 
indicated  on  the  analyses? 

10.  If  not,  why?  What  chenges  would  you  make?  Why? 

11.  Is  the  time-line  analysis  information  relevant  to  your  task 
of  drawing  the  panels?  Does  that  information  assist  you  in  making 
these  drawings? 

12.  Does  the  lime- line  analysis  information  have  any  application 
other  than  to  the  task  you  have  today?  Could  you  have  used  it  earlier? 
Might  it  be  useful  later? 

13.  What  design  Duplications  can  you  draw  from  the  time-line 
analyses? 
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SESSION  6B 


Instructions  For  Participating  Engineers 


In  this  session  information  has  been  made  available  by  the  Personnel 
Subsystem  Group  concerning  the  personnel  who  will  be  operating  and 
maintaining  the  PTPS.  This  information,  contained  in  the  enclosed 
memorandum,  contains  preliminary  Quantitative  and  Qualitative  Personnel 
Requirements  Information  (QQPRl)  for  the  PTPS.  Hiis  information,  broken 
out  by  the  Air  Force  Speciality  Code  (AFSC)  describing  the  job.  Includes 
position  (job)  descriptions  and.  manpower  estimates.  There  is  no  additional 
equipment  information  available. 

If  you  have  not  completed  your  sketches  of  the  control  panels 
required  in  the  previous  session,  this  session  will  enable  you  to  do  so. 

In  this  session  we  would  also  like  you  to  list  the  individual  steps 
required  to  operate  the  control-display  equipment  and  to  perform  any 
other  personnel  operations  you  think  necessary.  List  these  steps  in 
terms  such  as  "turn  on  power",  "monitor  I2J2  pressure",  "open  valve 
manually",  etc.  Keep  in  mind  that  safety  is  a  prerequisite  for  any 
operation.  List  the  steps  in  the  older  in  which  they  should  be  performed. 
Indicate  any  overlapping  steps.  Where  any  step  requires  more  than  one 
man  to  perform  it,  please  indicate  the  number  required. 

I  should  also  ] ike  to  ask  you  the  following  questions: 

1.  Do  you  have  enough  information  et  this  stage  of  PTPS  develop¬ 
ment  to  be  able  to  list  the  operating  steps? 

2.  If  not,  what  information  dc  you  think  you  neec'  or  would  want? 

3.  What  personnel  information  would  you  ordinarily  have  at  this 
stage  of  PTPS  de /eiopment?  Is  this  information  sufficient?  What 
personnel  information  would  you  want? 

4.  Do  you  find  any  of  the  personnel  information  you  have 
received  previously  to  be  useful  in  performing  the  task?  If  so,  what 
information  is  this? 

The  followii  g  questions  are  asked  of  experimental  subjects  only: 

5.  Do  you  have  any  difficulty  understanding  +he  QQPRl? 

6.  If  60,  what  is  the  problem? 

(.  Would  you  expect  to  receive  information  of  this  type  at  this 
stage  of  PTPS  development? 
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8.  Do  you  find  the  QQPRI  information  viseful  in  helping  you  with 
the  list  of  operating  steps?  If  so,  in  what  way? 

9.  What  design  implications  can  you  draw  from  the  position 
descriptions;  from  the  manpower  estimates? 

10.  Do  you  feel  that  the  information  contained  in  the  QQPRI  has 
any  major  impact  upon  your  design?  Would  you  change  your  design  in 
any  way  because  of  the  QQPRI? 
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Preliminary  Quantitative  And  Qualitative  Personnel  Requirements 

Information  (QQPKO  ’ 


lb:  Design  Engineering  Group,  FTPS  Project 

From:  Hunan  Factors  Section,  Personnel  Subsystem  Group 

Subj . :  Preliminary  Quantitative  and  Qualitative  Personnel 

Requirements  Information  (QQPRl) 


In  accordance  with  the  statement  of  voile  for  the  PEPS  program, 
paragraph  10.3,  the  liman  Factors  Section  has  performed  the  requisite 
analyses  and  has  drawn  up  a  preliminary  schedule  of  Quantitative  and 
Qualitative  Personnel  Requirements  Information  (QQPKl)  for  the  PTES. 
The  results  of  this  effort  are  appended  to  this  mcmorazvlm  and  are 
submitted  to  the  FTPS  Design  group  for  its  use  in  the  PEPS  design. 


Analysis  of  the  functional  requirements  of  the  FTPS  within  the 
contractual  constraints  Imposed  by  the  customer  has  allowed  us  to 
arrive  at  the  following  preliminary  manpower  estimate  for  operation 
and  maintenance  of  the  Titan  X  SLV,  Propellant  Transfer  and  Pressuriza¬ 
tion  System. 

Position  Descriptions 

The  following  Air  Force  specialities  have  been  identified  as 
those  requiring  the  least  amount  of  special  training  and  familiarization 
before  reaching  proficiency  in  operation  of  the  system. 

1.  Fuel  Supply  Officer  (FSO)  (AF5C  64^4) :  will  direct  pre-laimch 
operation  activities. 

-  will  assign  technicians  and  specialists  to  launching  crews 

-  will  supervise  propellant  transfer  operations  from  transporters 
to  RSV’s  and  from  RSV's  to  the  launch  vehicle 

-  will  determine  fuel  load  for  launch  vehicle 

-  will  direct  emergency  operations 

2.  Fuel  Specialist/Supervisor  (fS/s)  (AJSC  6435C®/TOB):  will  be 
responsible  for  the  receipt,  storage,  issue  and  transportation  of 
cl ss lie  fuel,  oxidizers  and  gases.  He  will  also  accomplish  routine 
maintenance  aoi  servicing  of  the  PEPS,  le  vill  assist  the  Liquid  Fuel 
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SESSION  ?A 


Instructions  For  Participating  Engineers 


In  this  session  we  would  like  you  to  analyze  the  potential  operating 
problems  which  might  be  encountered  after  the  FTPS  system  is  put  into 
use-  The  reason  for  doing  such  an  analysis  is  that  you  may  be  able  to 
include  in  your  design  certain  features  which  might  prevent  the  occurrence 
of  such  problems.  Your  list  of  operating  problems  should  contain  the 
following: 

1.  Description  of  the  problem  in  one  or  at  most  tvo  sentences; 

2.  Severity  of  the  problem  in  terms  of  its  consequences  for 
congjletion  of  propellant  transfer  and  safety  of  personnel. 

We  suggest  the  following  categories  which  you  can  abbreviate 
as  A,  B  or  C: 

A.  Catastrophic  —  extreme  danger  to  system  and/or  personnel; 

B.  Serious  --  failure  to  complete  propellant  transfer; 

C.  Minor  --  maximum  effect  is  delay  in  completion  of 
propellant  transfer. 

3.  Description  of  anticipated  s.onsequer  cs  to  PTPS  operation  in 
one  cr  two  sentences; 

h.  Design  recommendations  to  reduce  likelihood  of  error  occurrence. 

To  help  you  in  this  job  the  preliminary  QQPRI  given  you  in  the 
previous  session  has  been  considerably  expanded  (Figure  10A)  to  include: 

1.  A  list  of  duties  and  tasks  for  each  Air  Force  Speciality  Code 
(AJSC)  together  with  the  potential  personnel  errors  that  might 
be  made; 

2.  Ihe  performance  reliability  associated  with  these  tasks; 

3*  The  skill  level  estimated  to  be  required  for  each  task; 

4.  A  description  of  the  job  required  of  each  AFSC,  including 
the  skills  involved; 

5.  The  training  required  to  sake  each  individual  proficient. 

0QJPRI  given  only  to  experimental  subjects 
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I  would  like  to  ask  the  following  questions: 

1.  Do  you  have  enough  equipment  information  at  this  stage  of 
PEPS  development  to  be  able  to  list  the  potential  problems?  Enough 
information  about  PEPS  personnel  and  their  operations? 

2.  If  not,  what  information  do  you  think  you  need  or  would  want? 

3.  What  personnel  information  would  you  ordinarily  have  at  this 
stage  of  PEPS  development?  Is  this  information  sufficient  to  be  able 
to  list  the  potential  problems?  What  personnel  information  would  you 
want? 


h,  Do  you  find  any  of  the  personnel  information  you  received 
in  previous  sessions  helpful  in  making  up  the  list  of  problems?  If  so, 
what  information  is  this? 

5.  Can  you  say  whether  sore  of  these  operating  problems  are 
equipment-initiated  than  personnel-initiated? 

"5.  As  a  result  of  listing  the  operating  problems,  would  you 
change  your  design  in  any  way?  Add  or  delete  anything? 

7.  Could  you  solve  these  problems  without  design  changes? 


The  following  questions  are  asked  of  experimental  subjects  only: 

8.  Do  you  have  any  difficulty  in  understanding  the  QQPRI? 

9-  If  so,  what  is  the  problem? 

10.  Would  you  expect  to  receive  information  of  this  type  at 
this  stage  of  FTPS  development? 


For  each  of  the  categories  ..f  QQPRI  information,  ask  the  following 
questions: 


11.  Do  you  find  the  QQPRI  information  useful  in  helping  you  with 
the  list  of  potential  problems?  If  so,  in  what  way? 

12.  What  design  implications  can  you  draw  from  each  of  the  items 
of  QQPRI  information? 

13*  Do  you  feel  that  the  information  contained  in  the  QQPRI  in 
any  way  influenced  your  list  of  problems?  If  so,  in  what  way?  Would 
it  have  any  impact  upon  your  design? 
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At  the  conclusion  of  the  session  the  lnvestigacor  will  concentrate 
on  a  review  of  the  potential  operating  problems  to  determine: 

a.  Why  the  engineer  feels  it  is  a  problem; 

b.  Whether  the  existence  of  the  problem  will  in  any  way  affect 
his  desigi; 

c.  What  information  he  feels  he  should  have  in  order  to  resolve 
the  problem. 
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SESSION  7B 


Instructions  lb  Participating  Engineers 


This  session  should,  be  considered  as  a  continuation  of  the  previous 
one.  Consequently,  there  are  no  nev  inputs  available  to  you.  If  you 
have  not  finished  your  review  of  your  design  in  relation  to  the  QQPRI 
furnished  you  previously,  please  do  so.  This  review  will  assist  you 
in  performing  your  major  task  today,  which  is  to  supply  as  complete  list 
of  all  the  hardware  you  would  include  in  the  FTPS  as  you  can.  In  makiiig 
up  this  list,  please  include  the  following: 

1.  Type  of  component  (e.g. ,  globe  valve,  flex  hose,  filter, 
fluid,  press); 

2.  Location  of  component  (e.g.,  SLV  vent  to  FLU  line,  RSV  #1 
return  line); 

3.  Component  function  (e.g.,  shut  off  valve,  drain  valve, 
filter,  emergency  relief). 

We  would  also  ^ike  you  to  flag  each  conponent  which  would  be  directly 
operated  (not  maintsvned)  by  FTPS  personnel.  Do  not  flag  components  which 
function  only  indirectly  as  a  result  of  some  personnel  activation  (e.g., 
the  operation  of  a  filter  which  results  from  personnel  initiating  fuel 
transfer).  The  flagging  of  components  in  terms  of  personnel  operations 
will  help  us  to  define  the  impact  of  personnel  on  system  design  in  terms 
of  the  percent  of  components  related  to  personnel  operations. 

While  it  is  desirable  that  your  list  be  as  complete  as  possible, 
it  is  unnecessary  to  break  the  list  dewr.  to  a  level  of  detail  which 
includes  individual  nuts  and  bolts.  Where  you  know  or  can  guess,  you 
should  include  major  components  internal  to  a  higher  order  assembly 
(e.g.,  pump  in  a  FLU).  The  information  you  provide  should  be  such  that 
a  pricing  specialist  can  take  the  list  and  make  "ballpark"  estimates 
of  the  cost  of  your  subsystem  design. 
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SESSION  8 


Instructions  For  Participating  Engineers 


As  sometimes  occurs  during  system  development,  the  System  Project 
Office  (SPO)  monitoring  that  development  may  impose  changed  requirements 
upon  the  contractor.  The  memorandum  you  have  Just  received  indicates 
that  the  original  statement  of  work  provisions  (paragraph  7.1)  regarding 
the  number  and  composition  of  the  PTPS  work  force  have  been  changed. 

The  SPO  therefore  requires  you  to  examine  your  subsystem  design  to 
determine  whether  you  can  modify  that  design  to  meet  the  changed 
requirements.  Note  that  the  basic  functions  of  the  PTPS  remain  unchanged 
and  your  design  must  still  accomplish  those  functions. 

Your  task  today  will  require  you  to  review  the  engineering  and 
personnel  ingut6  you  have  received  to  date.  As  ye  .  do  so,  list  the 
following  on  a  sheet  of  paper: 

1.  All  changes  in  equipment  requirements  and  characteristics 
which  will  permit  the  desired  changes  in  number  and  type  of  personnel. 

2.  All  changes  in  operating  procedures. 

3.  All  changes  in  control-display  hardware. 

In  each  case,  the  reason  for  the  change  and  its  anticipated  Impact 
upon  personnel  performance  and  crew  composition  should  be  noted. 


Before  you  begin  your  review,  however,  I  should  like  to  ask  the 
following  questions: 

1.  Is  It  clear  what  you  are  being  asked  to  do?  If  not,  what, 
would  you  like  to  know? 

2.  Are  the  changed  personnel  requirements  reasonable,  in  your 
opinion? 

3.  Do  you  have  enough  information  to  perform  the  task? 

4.  If  not,  what  equipment  information  do  you  think  you  need? 

5«  What  personnel  information  do  you  think  you  need; 


Redirection  of  Design  Effort 


Clhe  following  was  provided  to  the  high  skill,  low  number  subjects 
(  Group  l)J 


_ ,  1967 

To:  Chief  Engineer,  FTPS  Project 

Prom:  Project  Officer,  Titan  X  SLV  Project 

3ub j . :  Redirection  of  Design  Effort 

Ref.:  Statement  of  Work,  Air  Force  Contract  423-6^70-1-67 


1.  Reference  statement  of  work  (paragraph  7*l)  requested  that  the 
contractor  design  and  develop  the  Titan  X  SLV  propellant  transfer  and 
pressurization  subsystem  (PTPS)  for  operation  and  maintenance  by  a  small 
number  of  highly  trained  Air  Force  specialists.  In  any  design  situation 
in  which  skill  level  and  number  of  personnel  had  to  be  traded  off,  it 
was  desired  that  the  criterion  of  minimum  number  of  personnel  was  to 
take  priority.  This  has  resulted  in  a  PTPS  design  which,  in  the  opinion 
of  this  office,  tends  to  make  excessive  demands  on  the  availability 

of  skilled  Air  Force  specialists. 

2.  It  is  therefore  directed  that  the  contractor  examine  the  present 
PTPS  design  configuration  and  recommend  such  changes  as  will  permit  the 
subsystem  to  be  operated  and  maintained  by  personnel  requiring  a  minimum 
amount  of  training  and  sVill  in  the  performance  of  their  duties. 

Although  it  is  recognized  that  any  reduction  in  the  training  and  skill 
level  of  operational  personnel  may  require  an  increase  in  system  manning, 
any  such  increase  should  be  kept  to  a  minimum  consistent  with  the  safe 
and  efficient  performance  of  the  PTPS.  The  total  composition  of  the 

PTPS  crew  should  not  exceed  N.  JVariable  number  adjusted  to  each  designer's 
original  manning  estimate^  All  non- supervisory  personnel  should  have 
no  higher  than  a  "5"  level  skill  rating,  with  50$  of  the  group  to  be 
composed  of  "3"  levels.  Basic  PTPS  functions  and  performance  require¬ 
ments  shall  not  be  affected  by  any  proposed  design  changes.  Moderate 
cost  increases  will  be  permitted  but  must  be  specified  in  'detail  and 
shall  be  acceptable  only  where  a  design  change  is  warranted  by  its 
effect  on  crew  composition. 

3.  Within  30  days,  therefore,  the  contractor  will  supply  this  office 
with  a  memorandum  listing  those  aspects  of  system  design  which  he  feels 
can  be  modified  to  reflect  the  revised  personnel  requirements. 
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4.  The  following  design  factors  shall  be  considered  in  your  analysis: 

a.  the  allocation  of  functions  between  equipment  and  personnel; 

b.  the  des^ jn  of  controls  and  displays; 

c.  operating  procedures; 

d.  safety  precautions; 

e.  the  speed  with  which  PTPS  operations  can  be  performed; 

f.  requirements  for  auxi'iary  test,  maintenance  ana  instrumentation 
equipment  used  by  personnel. 

Major  design  modifications,  together  with  their  predicted  effects, 
shall  be  described  in  detail. 

The  above  redirection  constitutes  an  addition  to  the  scope  of  the 
referenced  contract.  Estimates  of  the  cost  required  to  perform  the 
above  analysis  shall  be  supplied  to  Mr.  Robert  E.  Poihemus,  Titan  X  3LV 
Contracting  Officer.  Technical  questions  shall  be  referred  to  Major 
David  Jones,  Assistant  Project  Officer,  Titan  X  3LV  project. 


By  direction  _ 

Edward  B.  Rothermere 

Col.,  USAF 

Project  Officer 

Titan  X  SLV  Project  Office 
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[The  following  was  provided  to  low  skill,  high  number  (Group  II) 
subjects.^ 


_ ,  19&7 

To:  Chief  Engineer,  PEPS  Project 

From:  Project  Officer,  Titan  X  SLV  Project 

Subj.:  Redirection  of  Design  Effort 

Ref.:  Statement  of  Work,  Air  Force  Contract  423-647C-1-67 


1.  Reference  Statement  of  Work  (paragraph  7*1)  requested  that  the 
contractor  design  and  develop  the  Titan  X  SLV  propellant  transfer  and 
pressurization  subsystem  ( PTPS)  for  operation  and  maintenance  by 

Air  Force  personnel  who  would  require  a  minimum  amount  of  training  and 
skill  in  the  performance  of  their  duties.  The  requirement  for  minimum 
skill  level  was  considered  to  have  priority  over  other  manning  criteria, 
including  the  number  of  personnel  required. 

2.  An  analysis  of  Air  Force  manning  resources  has  indicated  that  a  sub¬ 
stantial  number  of  skilled  personnel  in  the  speciality  codes  required 

by  the  PTPS  will  be  made  available  for  this  program  by  the  progressive 
phasing  out  of  earlier  Titan  models.  In  view  of  this  development  it 
may  be  possible  to  achieve  reductions  in  the  total  size  of  the  PTPS 
manning  by  making  appropriate  design  modifications  reflecting  the  changed 
nature  of  personnel  requirements.  As  a  design  goal,  it  is  requested 
that  the  contractor  examine  the  possibility  of  manning  the  rTPS  with 
a  total  of  N  personnel.  [Variable  number  adjusted  to  each  designer's 
original  manning  estimate  J  It  is  anticipated  that  all  FTPS  personnel 
will  have  not  less  than  a  "7"  level  skill  rating. 

Basic  PTPS  functions  and  performance  requirements  shall  not  be 
affected  by  any  proposed  design  changes.  Moderate  cost  increases  will 
be  permitted  but  must  be  specified  in  detail  and  shall  be  acceptable 
only  where  a  design  change  is  warranted  by  its  effect  on  crew  composition. 

3.  It  is  therefore  directed  that  the  contractor  examine  the  present 
design  configuration  of  the  PTPS  and  recommend  such  changes  as  will  permit 
the  subsystem  to  be  operated  and  maintained  by  a  small  number  of  highly 
skilled  Air  Force  personnel.  The  primary  criterion  in  proposing  design 
modifications  shall  be  the  reduction  of  manpower,  consistent  with  the 
safest  and  most  efficient  performance  of  the  PTPS. 

Qtamainder  of  memorandum  includes  same  material  as  previous  memorandum^} 
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SESSION  9 


Instructions  For  Participating  Engineers 


In  this  session  we  are  going  to  deviate  a  little  from  our  previous 
procedure  by  giving  you  a  number  of  special  problems  to  solve. 

1.  -Administer  item  10  of  Test  II  as  described  in  Meister  and 
Sullivan,  19^7 •  See  Table  13  in  this  report  for  specific  sub-items. 

2.  I  want  you  to  review  mentally  the  various  items  of  information 
I  gave  you  during  your  subsystem  design  these  past  weeks.  Here  is  a 
deck  of  cards,  on  each  of  which  one  of  these  inputs  is  described. 

Take  the  cards  (the  investigator  will  shuffle  them  first)  and  look  at 
each  one  carefully  In  order.  After  you  have  looked  at  each  card,  I 
want  you  to  arrange  them  in  the  order  in  which  you  consider  each  item 
of  information  to  have  been  valuable,  useful  to  your  design.  In  other 
words,  place  the  card  with  the  most  useful  input  first,  the  card  with 
the  next  most  useful  input  next,  and  so  on  for  each  card.  0>ee  Table  10 
in  this  report  for  specific  items. Jj 

After  the  engineer  sorts  the  cards,  review  with  him  the  reasons 
why  he  sorted  them  In  this  way.  Etaphasize  the  following  points: 

a.  Did  the  input  provide  any  useful,  information; 

b.  Did  the  input  have  any  effect  on  your  subsystem  design; 
if  not,  why; 

c.  Was  the  sequencing  of  the  input  appropriate. 

3.  Ask  the  engineer  to  pick  out  which  of  these  inputs  he  would 
wish  to  have  at  the  very  start  of  design.  Why? 

4.  I  would  like  you  to  think  now  of  two  design  situations, 
in  both  of  which  you  are  to  design  a  propellant  transfer  subsystem 
something  like  the  one  you  have  just  finished  designing.  In  the  first 
situation  you  will  design  for  your  own  Marquardt  technicians.  In  the 
second  situation  you  will  design  for  Air  Force  personnel  who  have  had 
no  prior  experience  in  propellant  transfer  work,  but  who  will  be 
graduates  of  a  3  months  Air  Force  course  in  missile  operations.  The 
subsystem  shall  be  designed  so  that  the  Air  Force  personnel  can  operate 
and  maintain  the  subsystem  without  any  Marquardt  assistance  or  consulta¬ 
tion.  In  every  other  way  the  design  requirements  (e.g.,  reliability, 
duration  of  the  operating  cycle,  etc.)  are  the  same  for  th?  two  situations. 
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Assume  no  restrictions  lnposed  by  cost.  Primary  design  criteria  are 
safety  and  completion  of  propellant  transfer  to  mission  requirements. 

We  want  to  know  vhat  difference,  if  any,  the  differences  in  personnel 
would  make  to  your  design.  Here  is  a  list  of  subsystem  design  character¬ 
istics.  Put  a  check  mark  in  either  or  both  columns ,  depending  on 
whether  you  would  include  a  particular  characteristics  in  your  subsystem 
design.  You  may  of  course  include  the  same  characteristic  in  both  sub¬ 
system  designs  or  in  either. 


DESIGH  CHARACTERISTICS  MARQUARDT  AIR  FORCE 

1.  All  operations  performed  from  a 
central  control  station. 

2.  Some  valves  manually  operated, 
others  automatically. 

3.  All  operations  are  computer 
controlled;  personnel  functions 
are  restricted  to  starting  the 
operation  and  stopping  it  in 
case  of  malfunction. 

4.  Multiple  redundancy  built  into  all 
valves  and  other  major  equipment 
units. 

5.  Automatic  sensors  built  into  all 
valves,  control  units,  RSV’s,  etc. 
which  will  adjust  or  stop  flow  when 
preset  values  are  reached  or  an 
out  of  tolerance  condition  arises. 

6.  Schematic  display  of  all  valve 
positions  and  flow  conditions. 

7.  Only  critical  valve  positions  and 
flow  conditions  displayed. 

8.  No  displays  except  a  master  malfunction 
legend  light. 

9-  All  operations  performed  from  fuel 
carts  which  must  be  connected  and 
disconnected  as  required. 
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10.  Built  in  test  equipment  which  auto¬ 
matically  senses  out  of  tolerance 
conditions,  localizes  the  malfunctioning 
unit  and  displays  that  unit  location. 

11.  Manual  calibration  of  major  control 
units  (e.g. ,  flowmeters)  required  prior 
to  operation  of  subsystem. 

12.  Calibration  of  major  control  units  (e.g. 
flowmeters)  performed  automatically 
prior  to  subsystem  operation. 

13.  Continuous  personnel  monitoring  of 
individual  meters  describing 
propellant  flow. 

14.  Manual  adjustment  of  valve  controls 
to  make  final  "topping"  adjustments 
to  propellant  in  rocket  tanks. 

15*  Other  (to  be  supplied  by  subject, 
when  he  feels  that  other  design 
differences  would  exist) . 

After  the  subject  has  completed  this  item,  review  with  him  the 
reasons  for  his  choices. 

5.  You  have  been  given  the  task  of  designing  a  propellant  transfer 
subsystem  to  be  manned  by  Air  Fbrce  technicians  about  whom  you  know 
nothing.  Here  is  a  list  of  items  of  information  which  might  or  might 
not  be  of  use  to  you  if  they  were  included,  in  the  statement  of  work. 

Rank  these  factors  in  order  of  their  importance  to  equipment  design 
and  the  degree  to  which  they  should  influence  you  as  the  designer. 

JSee  lhble  11  for  specific  items. J 
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SESSION  10 


Instructions  For  Participating  Engineers 


Today's  session  will  involve  a  series  of  problems  similar  to  the 
ones  you  received  in  the  previous  session. 

1.  We  will  begin  by  asking  you  to  design  a  propellant  transfer 
system  to  the  same  functional  requirements  as  the  ones  listed  in  your 
original  statement  of  work.  There  will  be,  however,  one  major  difference. 
One  of  the  requirements  is  that  the  system  must  be  operated  and  maintained 
by  two  Air  Force  personnel  as  a  maximum.  No  further  information  about 
these  personnel  is  available.  Cost  should  be  a  consideration  in  your 
design,  but  not  the  primary  one.  You  should  take  advantage  in  your 
design  of  all  state-of-the-art  advances. 

We  wish  you  to  analyze  (in  as  much  detail  as  possible)  the  design 
requirements  for  such  a  system.  In  particular  we  would  like  to  know 
what  special  equipment  characteristics  and  modifications  to  your  original 
design  would  be  required  to  insure  its  operability  by  two  people. 

a.  In  designing  this  system,  what  were  the  major  items  of 
information  you  felt  you  needed  and  did  not  have? 

t.  You  will  be  given  a  se'  cards  to  sort.  These  cards 
contain  some  of  the  items  of  information  you  might  want  to  know  in  order 
to  develop  an  appropriate  design  for  the  system.  We  want  you  to  rank 
these  items  in  the  order  of  importance  you  feel  they  merit  in  terms  of 
enabling  you  to  develop  the  most  efficient  design.  Thus,  the  first 
card  you  would  place  on  the  table  would  be  the  most  important,  the  second 
card  you  would  put  on  top  of  this  would  be  next  most  important,  etc. 

[See  Table  XII  for  specific  items^ 

2.  I  would  like  to  find  out  whether  and  to  what  degree  your 
design  would  be  affected  by  certain  requirements,  if  these  were  included 
as  part  of  your  statement  of  work  and  no  waiver  were  permitted  by  the 
customer.  You  may  dislike  some  of  these  requirements  but  consider  that 
they  are  forced  on  you  by  the  customer.  Assume  you  had  the  job  of 
designing  a  propellant  transfer  system  something  like  the  one  you  have 
just  finished  designing.  Each  requirement  is  listed  on  a  card;  please 
examine  them  in  order  carefully  and  then  sort  them  into  three  piles, 

one  each  for  the  following  categories:  design  would  be  greatly  affected; 
design  would  be  slightly  affected;  design  would  not  be  affected  at  all. 
[See  Table  VIII  for  specific  itemsTj 
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APPENDIX  II 


DESCRIPTION  OP  SWUM  EFFECTIVENESS  NBASURES  EMPLOYED 
TO  COMPARE  OVERALL  SUBSYSTEM  DESIGNS 


RELIABILITY. 

The  reliability  prediction  made  vaa  baaed  on  the  following  require¬ 
ments: 

1.  The  prediction  desired  was  a  point  estimate  to  four  places  of 
the  probability  that  the  system,  once  activated,  will  perform 
its  mission  without  interruption.  The  system  has  two  mission 
segments:  (l)  to  transfer  propellants  from  the  railroad  to 
the  Itorage  area;  (2)  to  transfer  propellants  from  the  stor¬ 
age  area  to  the  rocket  tanks.  The  two  mission  segments  are 
independent,  that  is,  propellant  transfer  in  mission  segment 
(l)  will  not  necessarily  be  immediately  followed  by  transfer 
in  mission  segment  (2). 

2.  For  purposes  of  this  evaluation,  a  failure  was  defined  as  any 
equipment  malfunction  which  prevents  completion  of  the  sub¬ 
system  mission  (l.e.,  transfer  of  propellants).  Malfunction 
of  any  device  or  Interlock  which  was  required  for  safety  but 
which  did  not  physically  prevent  propellant  transfer  would 
also  be  considered  as  a  failure,  aince  personnel  would  not 
ordinarily  be  permitted  to  initiate  or  complete  transfer  once 
such  a  malfunction  was  noted. 

3.  The  probability  estimate  covered  an  operating  period  of  60 
hours  for  each  mission  segment. 

Schematics,  bills  of  material  and  operating  procedures,  as  supplied 
by  each  designer,  were  reviewed  and  coordinated  in  order  to  determine  the 
logical  aubdivision  of  each  system  into  its  constituent  elements  for 
which  failure  rates  and  corresponding  reliabilities  were  available.  Com¬ 
ponent  failure  rates  were  obtained  from  the  following  two  sources: 

Failure  Rates  ,  AVCO  Corporation,  Reliability  Engineering  Data 

Series,  no  date. 

RADC  Unanalyaed  Non  Electronic  Part  Failure  Rate  Data  ,  Technical 

Report  No.  RABC-TR-66-828,  Rome  Air  Development  Center,  Griffis  Air 

Force  Base,  New  York,  (1966). 
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The  general  processors  for  reliability  prediction  require*  four 
essential  step*.  These  are:  (l)  eye  tea  definition;  (2)  system  analysis; 
(3)  aodel  formulation;  (%)  model  solution  (quantitative  results), 

A  more  detailed  description  of  the  four  steps  follows: 

1.  System  Definition 

The  reliability  analyst  analyses  the  composition  and  configura¬ 
tion  of  the  system.  The  system  configuration  includes  the  system 
envelope,  its  functional  and  physical  boundaries,  the  objectives  of 
the  system  (i.e.,  its  sdssion(s))  and  a  definition  of  shat  const i- 
tues  system  failure.  The  latter  Includes  alteraate/degraded  modes 
of  operation. 

2.  System  Analysis 

The  analyst  must  then  investigate  the  system  to  ascertain  how 
the  constituent  parts  work  together  to  provide  the  required  func¬ 
tions.  Certain  parts  will  be  found  es sent  1x1,  others  nay  have 
redundant  counterparts  and  still  others  nay  not  be  required  at  all. 
The  results  of  this  analysis  culminate  in  the  construction  of  a 
reliability  or  probabilistic  block  diagram.  This  diagram  graphi¬ 
cally  illustrates  the  functional  interrelationship  of  equipment 
parts  including  alternate  although  perhaps  "degraded"  modes  of  op¬ 
eration.  This  diagram  does  not  necessarily  depict  signal  floe  but 
rather  the  system  parts  that  participate  in  each  aode  of  operation. 

3.  Model  formulation 

Using  the  probabilistic  block  diagram  constructed  in  the 
previous  step,  e  mathematical  modal  is  developed  which  permits  com¬ 
bi  net  ion  of  the  individual  equipment  reliabilities  into  an  evalua¬ 
tion  of  the  overall  system  reliability. 

It.  Modal  Solution 

Qaantltative  solution  of  the  modal  requires  determination  of  the 
reliability  characteristics  of  the  individual  eysten  elements.  This 
can  be  accomplished  in  several  ways  including  the  use  of  standard 
failure  rates,  data  sources  or  empirically  derived  data.  Once  these 
date  are  determined  they  are  inserted  into  the  mathematical  model  to 
obtain  the  overall  system  reliability. 

individual  substeps  include: 
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1)  suametion  of  failure  re  tee  for  e  group  of  essential, 
statistically  independent  elements  and. 

2)  conversion  of  e  failure  rate  to  a  probability  end 
suitable  combination  of  probabilities  where  the  step 
above  does  not  apply. 

Significant  characteristics  differentiating  the  subeystee  designs, 
which  affected  the  reliability  predictions  ore  listed  below: 

Subject  It 

Design  encludes  redundant  floweters  and  a  heater  subsystem 
1 —treed  in  the  R8V.  Design  does  not  include  either  puaps  ar  a 
T.V,  monitoring  system. 

Subject  8 

Design  includes  a  recirculating  beet  exchanger  subsystem,  and 
a  T.V.  monitoring  system.  Design  does  not  Include  redundancy  for 
its  pumps  or  flowmeters. 

Subject  J 

Design  includes  redundant  flowmeters,  but  locks  redundancy  for 
its  pump(s)  end  does  include  e  recirculating  beet  exchanger.  Other* 
wise  extremely  similar  to  Subject  N. 

Subject  D 

Design  includes  redundant  flowmeters,  a  T.V.  monitoring  system, 
end  e  n_ circulating  heat  exchanger  system;  does  not  include  redun¬ 
dancy  for  its  single  return  pump,  and  does  include  a  large  multi¬ 
point  temperature  recorder. 

Subject  H 

Design  Includes  redundancies  for  all  major  components  in  the 
system  such  as  pumps,  flowmeters,  computer,  RSV  tanks,  etc.  The 
design  is  also  distinguished  by  being  the  only  totally  automatic 
system  designed. 

Subject  K 


Design  is  distinguished  by  the  large  number  of  components  celled 


out,  the  T.V,  monitoring  system,  and  it*  redundant  pump*  and  flcw- 
m*t*r*. 


BASIC  DATA  FOR  COST  ANALYSIS 
TABIZ  XIV 


Distribution  of  Coats  Among  th*  Six  Subsystem* 


(*  X  1,000) 

Subjects 

J 

N 

8 

D 

H 

K 

1)  Tank* 

240 

200 

220 

200 

240 

250 

Tamp.  Control* 

75 

25 

45 

75 

75 

75 

Diaqp 

20 

20 

20 

20 

20 

35 

Flown* tar  Prover  8y».  ^go 

“sM 

tS 

“J? 

40 

375 

Hone 

165 

2)  Mechanical  Hardware 

215 

215 

164 

215 

284 

288 

Pump* 

• 

m 

40 

42 

81 

180 

”S5 

”£5 

”555 

”557 

”365 

158 

3)  Electrical  &  Instru 

.  69 

30 

30 

85 

86 

50 

Computer 

—■55 

“is 

—55 

”55 

4)  Major  Elect. 

18 

18 

25 

25 

25 

35 

5)  Console 

12 

10 

10 

12 

15 

12 

Display 

m 

«■ 

m 

20 

«• 

— I? 

15 

”15 

— & 

35 

”T? 

6)  Racks,  trays,  etc. 

8 

5 

5 

8 

12 

5 

Total 

707 

558 

609 

732 

1,198 

930 

SAFETY  EVALUATION  CRITERIA 


1)  Personnel  will  b«  provided  with  the  best  available  protective 
clothing  end  respiratory  equipment  end  safwty  protective  eye- 

teas. 

2)  Potential  personnel  upoeure  is  ideally  all,  except  that  two 
operations  oannot  within  Mechanically  feasibility  be  aade 
riote,  via. ;  connect  and  disconnect  of  road  vehicles  carry¬ 
ing  propellants,  and  connect  and  disconnect  of  flight  vehicles. 

3)  Propellant  dips,  bleeds,  drains,  discords,  etc.,  are  not 
released  to  the  ataosphere,  bat  are  contained  in  a  closed 
vessel  thus  eliminating  gross  atmospheric  pollution  and  pro¬ 
viding  for  disposal  or  reprocessing  under  controlled  conditions. 

4)  Propellant  and  preesurant  vents  are  processed  through  a  cheat cal 
solution  which  processing  renders  Inert  the  t carle  gases. 

5)  Propellant  flow  lines  and  systis  are  aesiwad  to  provide  ade¬ 
quate  design  safety  factors  ee  provided  in  applicable  codes. 

This  eeraptlon  applies  to  all  "code"  items  such  as  electrical, 
electronic,  deluge  end  shower  systems,  fire  and  heat  sensors 
and  warning  devices. 

6)  Manual  operations,  ideally,  are  reduced  to  a  minim  so  that 
human  error  as  well  aa  personnel  exposure  ia  minimised. 

7)  Repairs  and  maintenance  as  required  is  scheduled  at  non-crltlcal 
tima  end  under  conditions  that  paragraphs  (2)  end  (3)  ere  com¬ 
plied  with  to  e  iwIibm  degree . 

8)  All  propellant  watted  Items  are  assumed  to  be  of  Maxim  pro¬ 
pellent  oompatablllty  Insofar  as  selected  Materials  of  con¬ 
struction  are  concerned. 

9)  Site  utilisation  and  layout  will  comply  with  the  applicable 
DCS)  instructions  which  will  dictate  utilisation. 
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APPENDIX  III 


EXAKFJJfij  OF  DESIGN  OUTFUTS  DEVELOPED  BY  SUBJECTS 


* 


table  xy.  equipment  description  notes 


3.0  initiate  propellant  transfer 

3*1  START  RJEL  FLOW  -  A  remote  operated  fuel  control,  panel  will  be 
activated  to  start  the  transfer  pump. 

4.0  MONITOR  RJEL  TRANSFER 

Monitor  via  inst.  recorders  on  fuel  control  panel 

4.2  a)  Pump  inlet  pressure  (30  psig) 

b)  Pump  outlet  pressure  (150  psig) 

c)  Pump  RFM  (?) 

n)  Pump  discharge  temp. 

4.3  e)  RSV  liquid  level  (.AP  and  sight  glass  with  level 

transmitter) 

4.1  f)  Fuel  flow  rate  -  counts  and.  gal/min. 
g)  Fuel  temperature  at  meter 

EQUIPMENT  DESCRIPTION  -  PUMPING  OPERATION 

Flex  Hose  -  2"  -  Stainless  Steel  -  Teflon  lined,  continuous  helical 
convolution  and  SS  wire  mesh  100  psi 

Filters  -  2"  -  Mes>-  type  -  Stainless  Stee.  Wire,  10M  200  psi  rating  - 
locate  down  stream  of  pump  discharge 

Pumps  -  Canned  Type  (integral)  no  sniffing  box,  packing  gland  or 
mechanical  seal  -  impeller  should  be  mounted  directly  on  the  shaft  - 
sleeve  type  shaft  bearing  -  lubrication  provided  by  the  propellant 
pumped  (A- 50)  probably  3$,  60  n, ,  440  volts  -  discharge  pressure  150 
psig,  capacity  200  GIW 

Check  Valves  -  Swing  or  poppet  type  -  lowaP  (l. 0-2.0  psig) 

Valves  -  2,0  inch,  pneumatic  remote  operated  globe  type  (probably 
.Annin  Co.) 


CMj.  c  Ou  fltuui 

C4*4-+>) 


TABLE  XVI.  OPERATING  PROCEDURE 


OPERATING  PROCEDURES  FOR  TRANSFER  FROM  STORAGE  TANKS  TO  SLV 


6.0  Perform  SLV  Tank  Purge  and  Leak  Cheek 

1.  Connect  SLV  Flex  Hoses  to  appropriate  valves 

SLV-2-W-1  (Vent),  SLV-2-P7-1  (Press),  SLV-2-FV-4  (Fill),  2nd  Stack 
Relief  Valve,  SLV-l-W-1  (Vent),  SLV-l-PV-1  (Press),  SLV-l-FV-4 
(Fill),  1st  Stack  Rel.  Valve 

2.  Check  that  control  panel  is  de-energized  and  that  all  line  valves 
are  closed 

3.  Open  all  Syst.  Hand  Valves  -  RSV,  Line  Filters,  Instrumentation, 

GN2  Regulation  System  (use  Hand  Valve  Check-off  Sheet) 

4.  Energize  Propellant  Transfer  Panel  -  Confirm  by  Energy  Display 
Light 

5.  Open  Valves,  RSV-FV-kl,  RSV-FV-42,  RSV-FV-51,  RSV-FV-52,  RSV-FV-55, 
SLV-2-FV-1,  SLV-l-FV-1,  SLV-2-FV-3,  SLV-2-FV-2,  SLV-l-FV-3, 
SLV-l-FV-2 

6.  Open  GNg  Valve  GNp-l  or  GN2-2,  Pre-set  Pressure  Reg.  pressurizes 
entire  propellant  transfer  system 

7.  Monitor  Gauge  Pressure  (system)  using  pump  discharge  pressure 

8.  Isolate  system  pressure  by  closing  GNp  Purge  Valve  GNp-l,  or  GNp-2, 
monitor  pressure  gauge.  A  constant  drop-off  in  pressure  will 
Indicate  system  leakage.  If  leakage  is  detected,  institute 
corrective  action  check-off  list. 

9.  If  Syst.  Pressure  Check  is  O.K.  proceed  to  pressure  check  SLV-2  by 
opening  valve  SLV-2-FV-4  and  GN0-1  or  GN2-2  -  isolate  pressure  by 
closing  GN2-1  or  2  and  monitor  gauge  pressure  for  decay.  If 
leakage  is  detected,  institute  corrective  action  check-off  list. 

10.  If  SLV-2  is  O.K.  close  SLV-2-FV-4  and  proceed  to  pressure  check 
SLV-1  by  opening  SLV-l-FV-4  and  GN2-1  or  2  -  Repeat  Step  9. 


-  177  - 


APPENDIX  IV 


GUIDE  TO  THE  DEVELOPMENT  AND  USE  OF 
PERSONNEL  RESOURCES  DATA  INPUTS  IN  DESIGN 


Introduction 


The  purpose  of  this  Guide  is  to  describe: 

(1)  Those  PRD  inputs  which  are  particularly  relevant  tc  equipment 
design 

(2)  What  should  be  contained  in  these  inputs 

(3)  The  design  implications  that  can  be  drawn  from  these  inputs. 

The  Guide  is  directed  to  both  Human  Factors  specialists  and  engineers. 
The  former  will  want  to  know  what  and  how  PRD  inputs  should  be  developed; 
the  latter  will  be  particularly  interested  in  how  to  apply  these  inputs  to 
design. 

Since  this  Appendix  will  deal  with  only  those  PRD  inputs  which  might 
be  expected  to  exercise  an  influence  on  equipment  design,  it  does  not 
pretend  to  be  exhaustive;  other  inputs,  of  value  primarily  to  the  person¬ 
nel  specialist,  have  been  treated  superficially  or  ignored. 

The  developmental  time  span  in  which  these  inputs  are  developed  and 
applied  is  assumed  to  start  with  the  period  preceding  the  preliminary 
technical  development  plan  (PTDP)  and  to  extend  through  the  contractor 
definition  (IB)  phase.  The  reason  for  not  going  beyond  Phase  IB  i~  that, 
as  has  been  pointed  out  previously,  beyond  Phase  IB  the  probability  of 
influencing  design  significantly  is  very  slight.  Hence,  the  Guide  covers 
training  inputs  only  as  specification  requirements  and  does  not  deal  at 
all  with  test  and  evaluation  inpvits. 

This  Appendix  can  provide,  of  course,  only  an  outline  and  not  a  detailed 
description  of  each  PRD  input.  A  complete  treatment  of  the  topic  would 
require  another  report  as  lengthy  as  the  one  describing  the  present  study. 

Much  of  the  material  has  been  extracted  (and  modified  in  the  light  of 
the  study  results  from  Rabideau,  Cooper  and  Bates  (1961)  and  for  a  mere 
detailed  treatment,  particularly  of  the  mission/event  and  task  analyses, 
the  reader  is  referred  to  these  authors.  The  specific  application  of  the 
PRD  inputs  to  design  have,  however,  been  derived  from  the  results  of 
the  present  study. 
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The  following  analyses  and  inputs  will  be  covered: 

(1)  Mission/event  analysis 

(a)  Determining  system  requirements 

(b)  Segmenting  the  mission 

(c)  Identifying  system  functions 

(d)  Describing  personnel  functions 

(e)  Describing  personnel  function  interrelationships 

(2)  Task  analysis 

(a)  List  of  tasks 

(b)  Task  descriptions 

(c)  Task  sequence 

(d)  Task  criticality 

(e)  Task  duration 

(f)  Task  difficulty /err or  likelihood 

(g)  Time-line  analysis 

(h)  Position  descriptions 

(3)  Number  of  personnel  required 

(4)  Skill  descriptions 

(5)  Length/type  of  training  required 

(6)  Personnel  availability 

(7)  Personnel/equipment  analysis 

(8)  Inputs  required  for  the  PTDP  and  RFP/SOW  (Request  for 

Proposal /Statement  of  Work) 

Each  item  above  contains  the  following  information: 
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(1)  Definition  of  the  input 

(2)  What  the  input  should  contain 

(3)  Procedures  for  developing  the  input 

(4)  Developmental  phase /document  for  which  the  input  should 

be  supplied 

(5)  Design  applications 

(6)  Example  of  analytic  output  (abstracted  from  Rabideau  et  al. 

(1961)  and  slightly  modified  for  purposes  of  this  discussion) 
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PRD  INPUT  1:  MISSION /EVENT  ANALYSIS 


* 

f 


The  mission/event  analysis  is  begun  at  the  earliest  stage  in  system 
conceptualization  and  culminates  in  a  series  of  inputs  to  the  PTDP.  The 
mission/event  analysis  makes  possible  basic  decisions  regarding  the 
system  configuration,  e.  g.  ,  the  degree  to  which  the  system  should  be 
automated. 

There  are  four  reasons  why  this  analysis  should  be  performed  by  the 
Human  Factors  specialist:  (1)  to  secure  information  which  is  required 
for  the  specification  of  personnel  requirements  in  the  PTDP,  RFP  and 
SOW;  (Z)  to  familiarize  himself  with  the  system  with  which  he  will  have 
to  work  later;  (3)  to  check  the  system  configuration  developed  by  the 
engineer  to  insure  that  it  satisfactorily  takes  account  of  personnel 
factors;  (4)  to  influence  that  system  configuration  by  means  of  the  per¬ 
sonnel  information  he  provides  to  the  engineer. 

It  may  appear  to  the  reader  as  if  very  little  personnel-related  inform¬ 
ation  can  be  drived  at  these  very  early  stages  of  system  development. 

This  is  not  true.  Few  systems  are  complete  technological  innovations 
and  much  can  be  learned  by  analyzing  their  predecessor  systems.  In 
addition,  the  logic  of  system  design  comes  to  the  aid  of  the  personnel 
analyst.  Assume,  for  example,  that  the  system  requirement  is  to 
design  a  Mach  2  bomber  with  low-level  penetration  capabilities.  Re¬ 
gardless  of  any  other  special  functions  the  system  may  have,  the  air¬ 
craft  will  require  a  pilot  and  co-pilot.  It  will  have  to  take  off,  navigate 
to  a  predetermined  position,  release  its  bombs,  return  and  land.  Man¬ 
ifestly  certain  mission  segments  and  functions  are  automatically  implicit 
in  the  requirement.  Certain  cockpit  controls  and  displays  are  also 
obviously  required,  e.  g.  ,  altimeter,  radio  gear.  Examination  of  reports 
describing  advanced  avionics  concepts  will  help  the  analyst  conceptualize 
at  least  a  rough  configuration  or  envelope  for  the  aircraft.  Obviously, 
a  great  deal  can  be  deduced  from  basic  facts. 

The  entire  process  is  obviously  a  creative  one,  but  it  is  no  more 
creative  for  the  personnel  specialist  than  it  is  for  the  system  engineer, 
except  that  the  former  may  have  to  work  harder  at  gathering  the  equip¬ 
ment  information  which  may  be  more  available  tc  the  system  engineer. 

Mission/event  analysis  is  the  determination  of  the  operations  which 
must  be  performed  by  the  system  in  order  to  satisfy  system  mission 
requirements.  It  is  a  description  (in  verbal,  graphic,  tabular  and 
quantitative  form)  of  the  events  which  must  occur  in  order  for  the  system 
to  accomplish  its  stated  objectives.  As  such,  it  is  essential  that  the  per¬ 
sonnel  specialist  perform  this  analysis  along  with  the  system  engineer. 
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Since  every  system  requires  the  determination  of  equipment  functions, 
a  misaion/event  analysis  will  always  be  performed  by  engineers  to 
specify  the  equipment  characteristics  of  the  system.  This  engineering 
analysis  may  or  may  not  involve  personnel  factors,  probably  not.  Al¬ 
though  system  engineers  will  ordinarily  not  perform  an  exhaustive 
analysis  of  the  system's  personnel  requirements,  the  equipment  analysis 
they  perform  may  result  in  certain  configuration  decisions  which  deter¬ 
mine  and  constrain  personnel  functions.  The  personnel  specialist  must 
examine  these  equipment  decisions  to  determine  what  their  implications 
for  personnel  functions  are  and  whether  these  implications  are  acceptable. 

Mission/event  analysis  is  a  fairly  complex  process.  It  includes  a 
number  of  activities,  some  of  which  are  performed  concurrently,  so  that 
picking  them  out  as  individual  steps  (as  has  been  dune  in  this  guide)  is 
somewhat  arbitrary  and  largely  for  convenience  in  discussing  them. 
Moreover,  the  Human  Factors  specialists  should  realize  that  this  analysis 
cannot  be  divorced  from  its  equipment  aspects,  so  that  the  system  engineer 
may  well  have  performed  studies  which  overlap,  to  a  certain  extent,  with 
the  personnel  analysis. 

The  outputs  of  this  analysis  will  include  the  following,  which  should  be 
included  in  the  personnel  section  of  the  PTDP,  together  with  supporting 
data  extracted  from  the  analysis: 

(a)  An  estimate  of  personnel  to  be  included  in  the  operating/ 
maintenance  crew  of  the  proposed  system 

(b)  List  of  functions  to  be  performed  and  how  these  are  inter¬ 
related  or.  a  time  basis 

(c)  Descriptions  of  tasks  to  be  performed  to  the  most  detailed 
level  possible 

(d)  List  of  job  positions  for  the  personnel  specified,  referenced 
to  already  available  Air  Force  positions 

(e)  The  skill  level  required  for  each  job  position 

(f)  Length  and  type  of  training  required  for  each  position 


PRD  INPUT  1A:  DETERMINATION  OF  SYSTEM  MISSION  REOHREMENTS 


The  obvious  starting  point  (or  the  analysis  is  the  determination  of  what 
the  system  is  supposed  to  do.  Sources  of  information  about  the  proposed 
system  include  data  from  previous  systems  engineering  and  operations 
analyses,  the  resuits  of  any  preliminary  feasibility  studies,  government 
documents  describing  development  objectives,  etc. 

(1)  The  Human  Factors  specialist  must  determine  whether  already- 
established  system  determinants  require  that  the  system  be 
manned  and  the  basic  functional  purposes  for  the  manning.  Even 
if  the  system  is  unmanned,  almost  certainly  ground  maintenance 
functions  will  require  personnel  operations.  Since  the  system 
engineer  is  primarily  concerned  about  equipment,  he  may  main¬ 
tain  that  personnel  functions  are  minimal,  and,  therefore,  not 
worthy  of  detailed  examination.  The  Human  Factors  specialist 
should  in  any  event  examine  system  requirements  to  pinpoint 
those  areas  in  which  personnel  will  be  needed.  The  list  of  per¬ 
sonnel  areas  he  will  develop  should  suggest- -very  tentatively, 

at  this  point- -that  certain  control  equipment  will  be  needed  to 
facilitate  personnel  operations.  The  Human  Factors  specialist 
should  examine  the  engineer's  data  and  reports  to  determine  if 
the  latter  has  identified  those  points  of  personnel  functioning. 

(2)  The  Human  Factors  specialist  should  determine  whether  these 
functional  purposes  are  realistic,  in  the  light  of  known  human 
performance  capabilities  and  limitations.  For  example,  will 
a  technician  be  asked  to  lift  a  300-pound  weight?  If  so,  is  it 
planned  to  supply  the  appropriate  lifting  equipment? 

(3)  He  should  determine  the  general  ranges  of  environmental  vari¬ 
ables  to  which  personnel  will  be  exposed,  both  normally  and 
under  emergency  conditions.  Such  variables  may  be  acceleration, 
noise,  temperature,  etc.  In  addition,  response  requirements 
should  be  noted. 

(4)  He  must  determine  what  constraints,  e.  g.  ,  physical  envelope 
delimiting  the  crew  workspace,  speed  and  accuracy  require¬ 
ments,  etc.  ,  are  imposed  on  the  system.  Could  these  influence 
the  operator's  performance?  In  what  way?  Has  the  preliminary 
design  for  the  system  taken  account  of  these  constraints?  The 
Human  Factors  specialist  should  point  out  to  the  engineer  the 
potential  effects  of  these  constraints  on  performance  and,  if 
these  are  severe  limitations  for  personnel,  determine  whether 
alternative  configurations  are  possible. 
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At  this  initial  stage  of  personnel  resources  analysis,  only  a  few 
design  applications  for  the  data  can  V.  derived.  The  basic  purpose  of 
this  step  is  to  gather  necessary  data  for  more  detailed  analysis.  At 
the  same  time  the  examination  of  the  functional  purposes  for  the  humans 
in  the  system,  as  well  as  the  range  of  environmental  variables,  may 
suggest  certain  operational  conditions  under  which  personnel  may  be 
stressed  unduly  and  which,  therefore,  require  design  modifications. 
This  step  will  provide  preliminary  functional  allocation  data  to  be  used 
later  and  will  identify  dynamic  physical  variables,  e.  g.  ,  acceleration, 
noise,  heat,  which  need  further  analysis.  Data  on  static  physical 
variables  relevant  to  the  layout  of  workplaces,  housing,  access  can  also 
be  gathered. 
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TABLE  XVIII 


SM-X  SYSTEM  MISSION  REQUIREMENTS 


GENERAL  MISSION 

Strategic  Bombing  of  Targets  Within  1200  Mile  Range 


SYSTEM  DESCRIPTION 


General: 

Range- 

Payload: 

Propulsion: 

Guidance: 

Launch  Capability: 

Areas  of  Deploy¬ 
ment: 

Mobility: 

Missile: 

Nature  of  Site: 


Mid-Range  Ballistic  Missile 
Maxirr  un  1200  mile?,  minimum  400 
10,000  pounds 
Solid 

Inertial.  Not  susceptible  to  ECM  jamming 

All  missiles  off  ground  within  five  minutes 
following  strike  order 

All  climatological  and  geographic  conditions  north 
of  45  degree  N.  latitude 

Temporary  site,  15  minute  lead  time  to  initiation 
of  redeployment 

Roadable,  transportable  on  trailer-erector  vehicle. 

Soft  with  provision  of  mobile  living  quarters  for 
squadron  oersonnel.  Surveyed  bench  mark  required 
at  each  site  location 


Logistics:  Supply  from  closest  air  base,  maximum  separation 

200  miles.  Helicopter  requirement  for  personnel 
and  components 


MISSION  REQUIREMENTS 


Mission 

1.  Strategic  Bombardment  a. 

of  Military,  Industrial, 
and  Urban  Targets  with 
High  Yield  Weapons 


Mission  Requirements 

System  performance  such  as  to 
minimize  enemy  capability  for: 

(1)  Detection  of  missile 

(2)  Adequate  early  warning  and 

dispersal 

(3)  Interception  of  missile  or  ECM 
(4;  Retaliation 

(5)  Strategic  support  of  military 
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TABLE  XVIII  (continued) 


SM-X  SYSTEM  MISSION  REQUIREMENTS 


b.  Satisfactory  guidance  accuracy 

c.  Effective  control  of  warhead  burst 
altitude 

d.  Short  reaction  time  -  strike  order 
to  launch 

e.  Mobility  of  weapon  system 

f.  Low  initial  dollar  cost  per  operational 
missile  (and  associated  equipment) 

g.  Low  operations  and  maintenance  costs 

h.  Moderate  manpower  requirements 


PERFORMANCE  REQUIREMENTS 


Mission  Requirements 

Performance  Requirements 

Missile  Flight  Performance 

1. 

Engine  ignition  upon  firing  signal 

2. 

Acceleration  and  velocity  per  program 

3. 

Attitude  control  within  tolerance  limits 

4. 

Nose  cone  separation  per  program 
(following  engine  burnout) 

Guidance  Accuracy 

1. 

Circular  error  probability  (.  50) 
radius  of  three  miles 

Warhead  burst  altitude  control 

1. 

Detonation  at  preselected  altitude 
+  5,  000  feet 

Reaction  Time 

1. 

All  operational  missiles  launched 

within  15  minutes  following  strike  order 

.  Possible  requirement  for  automated 
launch  subsystem 

.  Continuous  monitoring  of  missile 

readiness  required,  implying  need  for 
fairly  extensive  display  subsystem 
.  Possible  requirement  for  highly  skilled 
maintenance  personnel 


TABLE  XVIII  (continued) 


SM-X  SYSTEM  MISSION  REQUIREMENTS 


Mission  Requirements 

Performance  Requirements 

Reaction  time  (concluded) 

2. 

Missiles  continuously  on  alert  (combat 
standby) 

3. 

Down  time  for  maintenance  not  in  ex¬ 
cess  of  10  percent 

Mobility  of  System 

1. 

Site  capable  of  initiating  redeployment 
within  15  minutes 

2. 

Total  time  required  for  site  setup  (to 
launch  time)  not  in  excess  of  30  minutes 
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TABLE  XVIII 


SM-X  SYSTEM  CONSTRAINTS 


System  Conatraints  Description 


Dollars 


Limited.  Total  availabe  for  R&D  - 
$100  million  . 


Schedule  Time 


Physical  Resources 

Availability  of 
Manpower 


R&D  complete  by  December  I960; 
Production  by  1964  . 

Unlimited  for  purposes  of  this  system  . 

Extremely  limited  en  re  AF  5  to  7  level 
personnel  with  missile  and  electronic 
AFSCs. 


Environmental  Programs 
Climate  and  Weather 

Wind 

Temperature  and 
Humidity 

Geography 


Atmospheric  Composition 
and  Contaminants 


Arctic,  continental  and  marine  climates 
as  found  in  Europe  north  of  45  degrees 
N.  Latitude.  Because  of  alert  require¬ 
ments,  system  must  be  capable  of  all 
weather  24-hour  operation. 

System  must  be  capable  of  launch  in  winds 
up  to  45  mph. 

See  climate  and  weather. 


Installation  may  be  located  on  any  terrain 
accessible  by  roads  of  less  than  7% 
grades.  Level  area  of  finite  dimensions 
required  for  site.  Tundra  may  provide 
a  problem.  Trees  may  provide  some 
cover  with  respect  to  aerial  reconnaissance. 

Not  relevant  to  mobile  open  site  and  solid 
propellant  operations. 


Lighting  and  Audition  Lighting  and  auditory  noise  anticipated  as 

design  problems  in  trailer  interiors. 
Communication  system  requires  lines 
from  living  quarters  to  operations  trailer. 
Also  need  alternate  means  of  communica¬ 
tions  between  wings,  squadrons,  and  sitea 


TABLE  XVII!  (concluded) 


SM  X  SYSTEM  CONSTRAINTS 
(cor  eluded) 

Environmental  Programs  Description 

Safety  Hazards  Accidental  detonation  of  warhead, 

premature  ignition  of  missile  power 
plant,  toppling  of  erect  missile,  falls 
from  work  platform,  electric  shock. 
Requirement  for  "buddy"  system  may 
increase  manpower  requirements. 
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PRD  INPUT  IB:  DIVISION  OF  THE  MISSION  INTO  SEGMENTS 


AND  IDENTIFICATION  OF  OPERATIONAL,  TASK 
AND  ENVIRONMENTAL  OPERATING  PERSONNEL 


Segmenting  is  an  arbitrary  process  which  serves  as  a  convenience, 
in  that  it  separates  what  may  be  a  protracted  mission  period  into  smaller 
segments  which  are  more  convenient  to  work  with  in  identifying  and  ana¬ 
lyzing  system  functions.  Segments  should  have  identifiable  start  and  end 
points. 

An  initial  step  in  segmenting  the  mission  is  to  draw  a  graphic  profile 
of  the  mission.  The  purpose  of  profiling  the  mission  is  to  describe  the 
potential  effects  on  personnel  performance  of  changes  in  system  variables 
throughout  mission  time,  from  a  preselected  starting  time  to  some  end 
point. 

The  profile  consists  simply  of  a  graphic  plot  of  the  various  stages  of 
the  system's  use,  e.  g. ,  take  off,  rendezvous,  bomb,  return,  etc.  The 
profile  is  plotted  on  a  real  time  base  --if  known- -otherwise  a  relative 
time  base. 

The  questions  which  the  personnel  specialist  asks  of  the  profile  are: 

(1)  What  is  the  human  supposed  to  do  at  any  particular  Doint  in  the 
mission? 

(2)  What  are  the  operational  factors  to  which  the  operator  will  be 
exposed  at  these  points? 

(3)  Can  the  operator  perform  his  functions  adequately  with  regard 
to  these  operational  factors? 

(4)  If  not,  what  must  the  design  configuration  be  in  order  to  permit 
the  operator  to  function  adequately? 

In  segmenting  the  mission,  the  procedure  is  to: 

(1)  Divide  the  mission  into  convenient  time  segments,  each  of  which 
has  a  cohesive  purpose  and  related  operations. 

(2)  Segments  should  represent  times  when  major  functions  start 
and  terminate. 
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(3)  Segments,  although  normally  end  to  end,  may  overlap,  provided 
that  analysis  indicates  a  time  overlap  of  differential  groups  of 
functions. 

(4)  Determine  or  estimate  the  probable  durations  cf  each  time 
segment. 

(5)  Graphically  arrange  segments  on  a  time  scale  for  checking 
completeness. 

The  mission  segments  themselves  are  not  useful  in  the  design  process 
except  insofar  as  they  help  in  identifying  those  points  at  which  the  opera¬ 
tional  environment  or  the  mission  requirements  may  tend  to  overload  the 
operator. 


TABLE  XIX 


SM-X  MISSION  SEGMENTS 


Segment 

Start  Time 

(in  minute 8) 

Segment 

Segment  Demarcation 

Variable  by 

Transport  system  equip¬ 

Deployment  order 

distance,  time 

ment  to  launching  site 

starts  at  site 

0 - — 

Assemble  missile  and 
prepare  pad 

Reach  site 

10  ' 

Erect  missile 

Missile  moved  to  pad 

15 

Activate  and  checkout 

Missile  in  launch 

missile  guidance  and 
control  subsystems 

attitude 

-  23 - ’ 

Insert  mission  and 
target  data 

Arm  and  fuze  tes<  OK 

Timehold 

Maintain  alert  status* 

Warhead  burst 

Indefinite 

i 

altitude  set 

I  .  „  1 

Arm  warhead 

Arm  order -redeploy 

|  ^  » 

1 

order 

- - 30 - J 

f  Launch  missile 

Fuzing  check  com¬ 
plete  strike  order 

- - 30 

Prepare  for** 

Redeployment 

Missile  launched 

Trailers  ready  to 
move 

This  segment  is  not 
Thi9  segment  is  not 


required  if  missile  is  to  be  launched  immediately, 
required  if  missile  is  launched. 
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PRD  INPUT  1C;  IDENTIFY  AND  DESCRIBE  MISSION/SYSTEM  FUNCTIONS 


Mission  functions  are  those  things  which  the  system  must  accomplish  in 
ordet  t?  *  the  system's  performance  may  meet  specifiable  criteria.  Func¬ 
tions  arv  usually  identified  by  verbs,  e.  g.  ,  select,  transport,  arm,  guide. 
Mission  functions  are  supposed  to  be  independent  of  equipment  design  con¬ 
siderations,  but  the  engineer  typically  combines  his  description  of  mission 
functions  with  the  equipments  he  feels  should  implement  these,  and  so 
equipment  functions  are  derived  concurrently  with  mission  functions. 

Every  mission  function  implies  an  equipment  and  personnel  function. 

It  is  the  Human  Factors  specialist's  job  to  identify  and  describe  these  per¬ 
sonnel  functions,  since  they  lead  directly  to  the  specification  of  the  per¬ 
sonnel  tasks  to  be  performed. 

D-»ta  sources  for  miss  on  function  identification  are  previous  mission 
profile  and  segment  data,  cystem  analysis/engineering  functional  data  and 
design  feasibility  data  concerning  subsystem  requirements.  The  orocedure 
for  determination  of  system  functions  is  to  examine  the  mission  profile/ 
segment  data  and  to  determine  what  continuous  or  long  duration  and  discrete 
or  short  duration  functions  are  required  to  implement  the  mission.  This  is 
essentially  a  judgmental  process,  which  means  that  no  clear  cut  procedural 
rules  are  available  to  describe  it. 

This  activity  is  essential  to  the  determination  of  personnel  functions, 
but  it  does  not  of  itself  lead  to  any  design  recommendations  which  the 
Human  Factors  specialist  can  suggest  to  the  engineer 
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TABLE  XX 


SYSTEM  FUNCTIONS,  MISSILE  SM-X 


Mission  Segment 

Transport  System  Equipment 
to  Launching  Site 


7 

L.  , 


Assemble  Missile  and  1. 

Prepare  Pad 

i. 

3. 

4. 

Erect  Missile  1 , 


System  F unction 

Supply  automotive  energy  to  transport 

a.  Missile 

b.  Warhead  and  n  se  cone 

c.  Guidance  modules  and  spares 

d.  Transporter  erector 

e.  Operations  trailer 

i.  Electrical  power  generator  trailer 
g.  Crew  quarters,  mess,  administra¬ 
tive  and  security  trailers 

Control  above  prime  movers  as  neces¬ 
sary  for  trip  from  air  base  to  site. 
Communications  equipment  and  proced¬ 
ures  required  for  communicating  among 
vehicle.?  daring  move. 

W ill  status  of  missile  and  warhead  have 
to  1  e  monitored  during  mow'’  it  so, 
how  will  movement  of  vehicles  affec? 
monitoring  displays7  What  must  and 
and  can  be  monitored  during  move7 

Transport  W/H,  nose  cone,  and 
guidance  modules  fo  missile 

Mate  components.  Mating  equipment 
required.  Implications  for  weights  o 
be  lifted  by  personnel. 

Attach  Components  and  physical  links. 
Stress  importance  of  identifying  com¬ 
ponents  for  fas?  assembly. 

Lay  portable  pad  s  ipport  for  mi,.3ile. 

Control  .ngular  movement  of  missile 
from  horizontal  to  vertical  position. 

Secure  missile  on  pad. 
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TABLE  XX 


SYSTEM  FUNCTIONS,  MISSILE  SM-X 


Mission  Segment 


Activate  and  check  out 
missile  guidance  and 
control  -lubsystems 


Insert  mission  and  target 
data 


Maintain  alert  status* 


Arm  warhead  upon  receipt 
of  strike  order 


System  Function 

1.  Activate  gyros  and  other  components 

2.  Activate  test  instruments 

3.  Check  yaw  accuracy 

4.  Check  roll  accuracy 

5.  Check  pitch  accuracy 

6.  Identify,  remove  and  replace  mal¬ 
functioning  units 

7.  Communicate  possible  no-go  situation 
to  launch  trailer 

8.  Test  warhead  arming  and  fuzing 
components 

1.  Orient  missile  in  azimuth 

2.  Insert  trajectory  tape 

3.  Set  warhead  burst  altitude 
(bombardment  mission) 

1 .  Periodically  monitor  all  loops  for 
in-tolerance  functioning 

2.  Provide  warning  when  malfunction 
exists 

3.  Isolate  out -of- tolerance  condition  to 
specific  module.  Because  of  require¬ 
ment  for  fast  reaction,  malfunction 
diagnosis  will  have  to  be  highly 
automated. 

4.  Remove  and  replace  module 

5.  Report  exijtiag  and  anticipated  missile 
out-of -commission  time. 

1.  Arm  warhead.  Safety  precautions. 

2.  Recheck  fuzing  system. 


This  function  is  not  required  if  misfile  is  to  be  launched  immediately. 
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TABLE  XX  (concluded) 


SYSTEM  FUNCTIONS,  MISSILE  SM-X 


Mission  Segment 

Launch  missile  upon  receipt 
of  strike  order 


System  Function 

Make  final  subsystem  checks 
(probably  all  automatic). 

Activate  firing  circuit. 

Clear  launch  area. 

Ignite  engine. 


Prepare  for  site  redeploy¬ 
ment  **  upon  receipt  of 
order 


Remove  missile  from  pad  to  TV 

Disassemble  missile,  nose  cone 
and  guidance. 

Li  ad  nose  cone,  guidance,  and 
spa  '•cs  in  helicopters. 

Disassemble  and  stow  launch  pad. 

Ready  all  trailers  for  movement. 


This  function  is  not  required  if  missile  is  launched. 
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PRD  INPUT  ID:  DETERMINATION  AND  DESCRIPTION  OF 


FUNCTIONS  TO  BE  PERFORMED 
BY  SYSTEM  PERSONNEL 


In  an  ideal  sense,  this  activity  involves  the  allocation  of  responsibility 
between  equipment  and  personnel  for  the  implementation  of  the  function. 
Supposedly,  this  is  performed  on  the  basis  of  determining  for  which 
functions  equipment  can  perform  in  a  manner  superior  to  personnel  and 
vice  versa. 

In  actual  practice,  the  nature  of  the  system  often  determines  that 
major  (top-level)  functions  be  performed  either  by  machines  or  by  men, 
and  no  conscious  allocation  of  responsibility  is  required.  For  example, 
a  human  car^iot  replace  a  jet  engine  as  the  power  plant  for  a  fighter.  On 
the  other  hand,  the  fighter  cannot  be  unmanned  (or  else  it  becomes  a 
missile). 

At  the  subfunction  level,  however,  there  may  be  alternative  ways  of 
performing  the  subfunction  and  here  tradeoffs  are  possible  (see  Tables 
XXI  and  XXII).  Thus,  a  question  might  arise  as  to  whether  bombing 
should  be  performed  automatically  by  radar  or  by  a  bombadier  using  an 
optical  sight  (or  by  both,  with  one  backing  up  the  other).  This  question 
might  have  to  be  answered  in  term*  of  the  accuracy  required  in  the 
bomb  run  as  compared  with  the  accuracy  capable  of  being  achieved  by 
the  human,  as  well  as  other  cost,  weight,  etc.,  factors  involved  in  the 
installation  of  an  automatic,  bombing  system.  In  such  tradeoff  situations, 
the  Human  Factors  specialist  will  input  data  concerning  known  human 
capabilities  and  limitations. 

The  formal  methods  reported  by  Rabideau  and  Bates  (1962)  which 
describe  how  one  allocates  functions  between  equipment  and  personnel 
are  largely  unused  in  the  actual  design  situation.  The  engineer  in  al¬ 
most  ail  cases  (given  equivalent  cost,  equal  ability  to  perform  the  func¬ 
tion,  etc.),  would  prefer  that  a  function  be  performed  automatically. 
Certain  off-the-shelf  hardware  impose  paiticuiai  personnel  functions. 

In  any  case,  the  length  of  time  available  for  making  decisions  of  this 
sort  is  not  unlimited  (as  seen  in  the  present  study)  and  all  the  formal 
methods  are  overly  complex. 

The  personnel  specialist  can  do  two  things  in  this  phase  of  the 
analysis: 

(1)  He  can  point  out  to  the  engineer  functions  which  require, 
because  of  their  special  demands,  human  imp'er:  en^ation 
Among  these  demands  are  complex  decision-making,  precise 
perceptual  discriminations,  etc.  He  can  list  these  special 
requirements  and  suggest  their  implications  for  design. 
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(2)  He  can  review  the  functional  allocations  made  implicitly  by 
the  engineer  to  determine  whether  the  functions  allocated  to 
personnel  will: 

(a)  stress  the  operator  and,  therefore,  lead  to  inefficiency 

(b)  require  special  kinds  of  equipment  to  permit  the  imple¬ 
mentation  of  the  function  by  personnel 

From  the  engineer's  standpoint,  this  kind  of  personnel  analysis  will 
suggest  where  special  kinds  of  equipment  are  required  to  assist  the 
human  in  performance  of  his  functions  or  where,  perhaps,  it  might  be 
advisable  to  replace  a  potentially  weak  human  link  with  an  equipment. 
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TABLE  XXII  (continued) 
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TABLE  XXIII 


SAMPLE  TASK  TIME  BASE  LAYOUT  FOR 
SM-X  MISSILE  SYSTEM  "ASSEMBLE  MISSILE"  MISSION  SEGMENT 


Function/ Task 

A.  Transport  W/H  etc. 

1.  Attach  sling  to  nose  cone 

2.  Position  crane  (truck 

mounted) 

3.  Attach  sling  to  hook 

4.  Hoist  ncse  cone  to  clear 

truck  bed 

5.  Rotate  nose  cone  forward 

6.  Position  truck  ahead  of 

ransporter  -erector 

B.  Mate  missile  and  nose  cone 

1.  Use  crane  and  truck 

to  mate  components 

C.  Attach  nose  cone  to  missile 

1.  Install  bolts  to  attach 
components 

D.  Lay  pad 

1.  Carry  sections  from 

T-E  to  pad  area 

2.  Assemble  sections  to 

form  pad 


0  2  4  6  8  10 
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PRD  INPUT  IE:  DESCRIPTION  OF  THE  INTERRELATIONSHIPS 


OF  PERSONNEL  FUNCTIONS 


Once  the  personnel  functions  have  been  specified,  it  is  necessary 
to  describe  how  they  interrelate.  The  personnel  functions  which  were 
determined  in  the  previous  analytic  step  are  now  assigned  to  the  ;  - 
dividual  stages  of  the  mission  as  described  in  the  mission  profile. 
Particularly  where  that  profile  has  a  time  ba:.e,  this  permits  one  to 
specify  the  sequence  in  which  personnel  functions  should  be  performed 
(see  Table  XIII).  The  result  can  be  described  graphically  in  the  form 
of  a  time-line  analysis  and  personnel  functional  flow  diagrams  (see 
PRD  Input  2C). 

There  are  no  specific  design  applications  of  this  analytic  step, 
primarily  because  the  'unction  level  (even  that  of  the  sub-function)  is 
still  too  gross  to  do  more  than  describe  the  personnel  aspect  of  the 
system  in  very  general  terms.  However,  it  will  permit  the  personnel 
specialist  to  check  the  allocation  of  functional  responsibilities  to 
system  personnel,  to  insure  that  too  many  functions  have  not  been 
assignedat  particular  stages  of  the  mission  to  personnel.  The  time¬ 
line  analysis  which  will  be  derived  as  a  function  of  the  task  analysis 
(PRD  Input  2)  is  also  an  essential  step  in  the  derivation  of  the  required 
number  of  system  personnel. 
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PRD  INPUT  2:  TASK  ANALYSIS 


Task  analysis  is  the  primary  method  for  developing  all  subsequent 
PRD  inputs.  It  follows  immediately  upon  performance  of  the  mission/ 
event  analysis.  The  outputs  of  the  task  analysis,  in  as  detailed  a 
format  as  possible,  should  be  available  as  inputs  to  the  PTDP,  and 
should  be  pregressively  refined  and  made  more  detailed  in  the  RFP 
and  SOW.  More  detailed  task  analyses  can  be  performed  after  design 
is  initiated,  but  in  general,  such  analyses  should  lead  or  at  Last  be 
concurrent  with  the  equipment  for  which  the  analyses  are  begun. 

Task  analysis  outputs  are  as  complete  a  description  as  possible  of 
how  the  operators  and  maintenance  personnel  in  the  system  will  func¬ 
tion.  From  the  task  analysis  implications  may  be  drawn  for  personnel 
requirements,  such  as  number  of  personnel,  skill  level,  job  positions, 
etc.  ,  all  of. which  have  major  design  implications  (which  will  be  dis¬ 
cussed  in  connection  with  the  individual  task  analytic  output). 

Task  analysis  outputs  include  the  following- 

(1)  Lists  of  tasks 

(2)  Task  descriptions 

(3)  Task  sequence 

(4)  Task  criticality 

(5)  Task  duration 

(6)  Task  difficulty/error  likelihood 

(7)  Time-line  analysis 

(8)  Position  descriotions 


A  task  is  a  complex  of  behaviors  (perceptual  discriminations,  motor 
responses,  decisions  and  analyses)  which  are  related  to  each  other  in 
terms  of  time,  immediate  purpose  and  a  common  man-machi-e  output. 

The  procedure  for  identifying  tasks  is  to  list  the  functions  to  be 
performed  by  personnel  (sec  PRD  Input  ID).  These  may  be  whole  func¬ 
tions  or  functional  elements  performed  wholly  or  partially  oy  the 
human,  in  which  the  human  initiates  some  action  or  die  action  is  directed 
at  the  human  or  in  which  the  operator  is  a  communicator  or  controller 
of  a  machine  function.  For  example,  the  following  might  be  functions: 
"Drive  tank,  navigate  to  IP  point;  diagnose  malfunctions.  " 


i 


The  tasks  and  their  functional  elements,  i.  e.  ,  sub-tasks,  should  be 
identified  and  labeled.  The  task  is  some  activity  which  implements  the 
overall  function  described  above,  as,  "Activate  engine;  plot  position, 
etc.  "  Sub-tasks  in  their  turn  implement  tasks,  e.g.  ,  "Advance 
throttle,  turn  steering  wheel,  engage  clutch,  etc.  "  Ordinarily  the 
task  should  involve  the  output  of  only  one  man  in  interaction  with  a 
machine  component.  Task  and  sub-task  labels  should  start  with  verbs 
which  indicate  the  nature  of  the  activity  being  performed. 

The  results  of  this  procedure  will  be  the  list  of  tasks.  To  secure 
task  descriptions  in  additional  detail,  it  will  be  necessary  to  analyze 
the  individual  tasks  to  specify  the  following; 

(1)  Equipment  or  personnel  inputs  which  initiate  the  performance 
of  the  task,  e.g.,  flashing  indicator,  verbal  message 

(2)  The  behavior  involved  in  task  performance,  e.g.  ,  activation 
of  the  throttle,  reading  of  a  meter 

(3)  Outputs  which  result  from  the  performance  of  the  task,  e.  g.  , 
lever  is  activated,  toggle  switch  is  thrown 

(4)  Feedback  available  to  the  operator  from  task  performance 
which  may  lead  to  next  task  in  sequence,  e.  g.  ,  verbal 
message  of  confirmation,'  indicator  light  illuminates 

(5)  Estimation  of  task  duration 

Tasks  are  then  grouped  into  positions.  A  position  is  a  combination 
of  tasks  bound  by  similarity  of  task  characteristics,  physical  location 
of  task  performance,  internal  sequence  of  operations  and  imposed  skill 
demands  so  as  to  form  a  natural  work  procedure  for  one  man.  The 
grouping  oi  tasks  into  positions  helps  to  determine  how  many  men  will 
be  required  and  approximately  what  the  individual  skill  requirements 
will  be. 

Tasks  are  grouped  into  positions  by  performing  the  following  steps; 

(1)  Lay  out  tasks  on  a  time  base.  Estimates  of  task  duration  are 
combined  with  data  concerning  the  time  phasing  of  the  tasks 
within  a  mission  segment. 

(2)  Estimate  task  skill  demands  on  the  basis  of  decision  and  per¬ 
ceptual/motor  requirements  levied  by  the  task  and  the  opera¬ 
tional  environment  on  the  operator. 
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(3)  Arrange  tasks  according  to  tentative  positions.  This  is 
"cut  and  try"  procedure.  The  attempt  is  made  to  reduce 
"idle"  time  (men  not  being  productively  employed)  to  a 
minimum. 

The  task  analysis  itself  is  a  methodology.  The  personnel  specialist 
is  concerned  with  communicating  only  the  outputs  of  the  analysis  to  the 
engineer,  not  the  methodology  itself,  which  is  of  interest  only  to  the 
specialist. 


PRD  INPUT  2A:  LISTS  OF  TASKS 


In  this  and  in  subsequent  descriptions  of  PRD  inputs  resulting  from 
the  task  analysis,  only  the  design  implications  of  the  input  will  be  dis¬ 
cussed,  since  the  procedure  for  developing  the  input  has  already  been 
described. 

An  example  of  a  task  list  is  provided  in  Session  1  of  Appendix  I. 

Note  that  the  task  list  provides  only  the  barest  amount  of  information 
to  the  engineer  and  should  be  supplemented  with  other  task  analytic 
outputs,  such  as  task  descriptions,  task  criticality  evaluations,  etc. 

As  a  minimum,  the  task  list  should  be  included  as  a  basic  input  to 
the  PTDP,  but  in  order  to  fully  satisfy  the  personnel  section  of  that 
document,  it  should  be  supplemented  with  other  task  information. 

The  engineer  is  likely  to  view  the  task  list  as  comparable  to  an 
operating  procedure  or  as  a  beginning  step  to  the  development  of  an 
operating  procedure.  This  is  useful  in  itself,  because  it  causes  him 
to  think  about  the  operational  uses  of  equipment  in  terms  other  than 
equipment  functioning.  As  described  previously,  the  engineer  seems 
temperamentally  loathe  to  think  in  operational  terms,  a  form  of  analysis 
which  is  required  for  incorporation  of  personnel  considerations  in 
design. 

The  task  list  may  suggest  to  the  engineer  that  certain  types  of 
control -display  equipment  are  needed  to  permit  implementation  of  the 
tasks.  For  example,  if  the  task  is  to  control  the  amount  of  pressure 
in  a  vehicle,  it  is  obvious  some  type  of  control  equipment  with  meters 
or  other  displays  will  be  required.  Since  this  deduction  is  relatively 
simple,  it  is  likely  that  the  engineer  will  make  the  same  deduction  also. 
However,  because  of  his  personnel  orientation,  the  specialist  may  be 
able  to  read  more  into  the  task  than  that,  particularly  if  the  task  is 
described  in  detail.  To  the  extent  that  the  task  list  is  detailed,  it  will 
help  suggest  the  general  syjtem  configuration  needed  to  permit  imple¬ 
mentation  of  these  tasks. 

In  presenting  the  information  to  the  design  engineer,  the  Human 
Factors  specialist  should  not  leave  it  to  the  engineer  to  draw  his  own 
implications  from  the  data  but  should  recommend  whatever  design 
implications  the  input  suggests  to  him.  This  is  a  general  principle 
which  applies  to  all  PRD  inputs.  The  system  description  in  the  PTDP 
should,  of  course,  incorporate  all  the  personnel  specialist's  concepts 
concerning  system  design  (those  which  have  survived  compromise  with 
the  system  engineer). 
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PRD  INPUT  2B:  TASK  DESCRIPTIONS 


The  task  description  is  a  more  detailed  description  of  the  task 
listed  in  Input  2A.  Preliminary  task  descriptions  should  be  available 
as  an  input  to  the  PTDP  and  more  detailed  task  descriptions  in  the 
RFP/SOW.  However,  it  is  unnecessary  and  unwise  to  present  to  the 
engineer  all  the  behavioral  details  with  which  the  personnel  specialist 
would  describe  the  task.  Indeed,  in  line  with  what  has  been  learned  in 
the  present  study,  it  is  preferable  to  describe  all  tasks  in  terms 
linked  as  closely  as  possible  to  system  operations. 

Highly  detailed  task  descriptive  information  should  be  extracted 
and  presented  in  the  PTDP  only  when  a  particular  task  is  significant 
for  design  because: 

(1)  It  has  a  high  probability  of  error 

(2)  It  has  special  skill  or  knowledge  demands 

(3)  It  is  especially  critical  to  system  performance  (see  Input  2D). 

With  regard  to  design  implications,  highly  critical  tasks  or  those 
with  a  high  probability  of  error  may  require  that  special  provisions  be 
made  to  accommodate  these  tasks  in  the  design  of  the  equipment  with 
which  the  task  may  require  guarding.  A  special  procedure  or  special 
feedback  indications  may  have  to  be  developed  for  such  a  task.  Inter¬ 
locks,  where  applicable,  may  have  to  be  designed. 

If  skill  requirements  for  a  particular  task  are  excessive,  the  pro¬ 
cedure  and  equipment  imposing  these  demands  may  have  to  be  modified, 
e.g,  ,  breaking  up  one  complex  task  into  two  simpler  ones.  A  change 
in  procedure  may  involve  a  change  in  equipment  design;  from  that  stand¬ 
point  procedural  changes  can  be  considered  p3rt  of  design  modifications. 
Performance  aids  may  be  another  solution.  The  point  is  tha*  the  task 
description  may  indicate  a  potential  problem  area  which,  when  brought 
to  the  engineer's  attention,  may  result  in  s  design  modification. 

Table  XXIV  presents  task  and  sub-task  descriptions  for  one  segment 
of  the  SM-X  mission. 
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HUMAN  FUNCTIONAL.  FLUENTS,  TASK  AND  SU  *.J TASKS  FOR 
ACTIVATION  AND  CHECKOUT  OF  GUIDANCE  AND  CONTROL  SUBSYST 
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PRD  INPUT  2C:  TASK  SEQUENCE 


Task  sequences  should  be  displayed  in  the  form  of  a  personnel 
functional  flow  diagram,  examples  of  which  are  presented  in  Figures 
4  and  5  in  Appendix  1.  Note  that,  the  diagram  will  indicate  major 
aecision  points  which  may  impose  skill  demands  on  the  operator. 

The  personnel  functional  flow  diagram,  the  purpose  of  which  is  to 
show  the  interrelationships  among  tasks,  should  be  available  to  the 
engineer  at  the  same  time  the  latter  is  developing  his  equipment  flow 
diagrams.  The  diagrams  should  also  be  included  as  part  of  the  PTDP. 

The  interrelationship  of  tasks  may  suggest  to  the  engineer  certain 
logical  groupings  of  functions  within  particular  equipments,  e.g.  , 
certain  task/function  groupings  which  are  related  might  be  incorporated 
in  one  set  of  control  equipment,  whereas  another  grouping  might  be 
implemented  by  another  group,  etc.  The  interrelationships  may  also 
suggest  the  necessity  for  communications  equipment.  Task  sequence 
data  will  also  be  useful  in  developing  preliminary  "top  level"  system 
operating  procedures  which,  in  turn,  will  structure  the  overall  system 
equipment  configuration.  The  grouping  of  tasks  will  help  to  suggest 
job  positions. 

The  Human  Factors  specialist  can  use  the  personnel  functional  flow 
diagram  as  a  meais  of  checking  on  the  adequacy  of  the  system  config¬ 
uration  by  comparing  diagrammed  personnel  events  with  corresponding 
diagrams  of  equipment  events.  A  one-to-one  correlation  must  exist 
between  any  personnel  function/task  and  its  corresponding  equipment 
function/ task.  Asynchrony  will  indicate  that  the  equipment  or  the  task 
must  be  modified.  Past  experience  suggests  that  in  initial  design  the 
engineer  may  overlook  the  necessity  for  supplying  equipment  to  imple¬ 
ment  personnel  task  requirements. 
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PRD  INPUT  2D:  TASK  CRITICALITY 


This  is  not  an  independent  output,  but  one  which  is  a  deduction  from 
the  nature  of  the  task  and  is  presented  to  the  engineer  with  the  task 
description  in  form  of  a  note  to  the  task  description. 

There  are  three  major  steps  in  the  derivation  of  task  criticality: 

(1)  Identify  the  potential  errors  which  can  be  made  in  performance 
of  the  task.  This  is  largely  a  matter  of  considering  the  ele- 
ments  of  the  task  and  the  perceptual,  motor  and  decision-making 
demands  imposed  on  the  operator.  Thus,  in  a  simple  case  of  a 
task  which  involves  (a)  reading  a  pressure  guage  regulating  the 
internal  pressure  of  a  rocket  and  (b)  stopping  a  pump  at  a  speci¬ 
fied  pressure,  errors  may  manifest  themselves  in  two  ways: 

(a)  failing  to  stop  at  the  prescribed  point 

(b)  stopping  the  pump  before  the  prescribed  point 

(2)  Identify  the  effect  of  each  potential  error  on  system  operation. 

Thus,  in  the  example  above,  failing  to  stop  the  pump  at  the 
prescribed  point  may  result  in  overpressurization  and  bursting 
of  the  rocket  being  pressurized.  Stopping  before  the  prescribed 
point  will  result  in  underpressurization,  so  that  certain  sensi¬ 
tive  instruments  requiring  a  pressurized  atmosphere  will  func¬ 
tion  erratically. 

(3)  Estimate  the  relative  criticality  of  the  potential  errors. 
Criticality  may  be  scaled  in  terms  of  categories  such  as,  loss 
of  personnel,  destruction  of  the  system,  mission  failure  or 
abort,  mission  degradation,  mission  delay,  etc.  In  these 
terms,  overpressurization  may  be  more  critical  than  under  - 
pressurization,  since  it  may  result  in  explosion  of  the  rocket 
and  destruction  of  the  rocket  and  launch  pad  as  well  as  loss  of 
life,  while  underpressurizatiou  is  less  critical,  since  the 
mission  may  (not  certainly,  but  may)  be  degraded. 

Pointing  out  a  task  as  being  critical  to  the  engineer  "flags”  that  task 
as  one  requiring  special  consideration  in  design.  Among  the  solutions 
which  are  possible  (certainly  the  list  is  not  exhaustive)  are: 


-  215  - 


(1)  Replacing  the  human  by  an  automatic  means  of  accomplishing 
the  function  if  the  desired  level  of  correct  performance  can¬ 
not  be  achieved  in  any  other  way 

(2)  Providing  means  to  reduce  the  probability  of  error,  e.g. , 
assigning  a  special  feedback  device  to  warn  the  operator  when 
the  task  is  being  performed  incorrectly 

(3)  Assigning  the  task  to  only  highly  skilled  personnel 

Task  criticality  is  highly  related  to  specification  of  task  difficulty/ 
error  likelihood.  Since  the  engineer  thinks  in  terms  of  physical  effects 
on  the  system,  it  is  preferable  to  flag  the  iask  as  being  critical  without 
indicating  that  it  also  has  a  high  difficulty/error  likelihood  index.  The 
provision  of  quantitative  indices  of  a  highly  precise  nature,  such  as  prob¬ 
ability  of  operator  error  to  four  figures  (e.g. ,  .  0013)  is  not  advised, 
since  the  engineer  cannot  interpret  the  quantitative  values  in  design¬ 
relevant  terms.  A  gross  categorisation  of  task  difficulty,  such  as  a 
three -part  scale: 

1.  simple,  routine 

2.  somewhat  difficult 

3.  very  difficult 

is  as  *iuch  precision  as  the  engineer  can  handle  in  design  terms.  More¬ 
over,  it  is  unnecessary  to  apply  the  above  scale  to  each  task,  but  only 
to  those  few,  very  critical  ones  which  merit  design  attention. 


-  216  - 


PRD  INPUT  2E:  TASK  "'URATION 


Task  duration  should  be  considered  in  two  ways: 

(1)  as  a  system  requirement,  i.  e. ,  the  time  within  which  the  task 
must  be  performed  in  order  to  accomplish  a  given  system 
function 

(2)  as  an  anticipated  human  performance  capability,  i.e. ,  the  time 
within  which  the  operator  can  actually  perform  the  task. 

Item  (1)  above  is  a  criterion  against  which  Item  (2)  can  be  evaluated 
as  satisfying  or  failing  to  satisfy  system  time  requirements. 

A 8  a  system  requirement,  a  task  may  have  to  be  accomplished  in  so 
short  a  time  period  that  the  operator  either  cannot  physically  perform 
the  task  in  that  time  or  the  probability  of  his  making  an  error  will  be 
substantially  increased  because  of  the  time -loading.  In  either  case, 
special  attention  must  be  drawn  to  such  a  task.  If  the  system  time  re¬ 
quirement  is  inflexible,  it  may  be  necessary  to  automate  the  function 
involved  (to  eliminate  the  operator),  or  else  to  redesign  the  manner  in 
which  the  task  can  be  performed  or  the  equipment  to  be  operated  or 
maintained. 

Task  duration  is,  of  course,  not  critical  unless  the  system's  required 
response  time  is  also  critical  to  the  successful  accomplishment  of  the 
mission.  Hence,  it  is  necessary  to  analyze  the  mission  segment  in  terms 
of  its  time  demands  before  examining  any  individual  task  duration.  In¬ 
formation  required  in  order  to  perform  task  duration  analysis  will  include: 

(1)  system  performance  time  requirements 

(2)  description  of  the  tasks  to  be  performed  by  personnel  in  each 
mission  segment 

(3)  estimated  time  required  to  perform  the  task 

Of  these  informational  requirements,  the  most  difficult  to  secure  is 

(3)  because  it  requires  data  on  the  performance  time  capability  of 
personnel  (e,  g. ,  hooking  up  an  umbilical  connection  usually  takes 
time).  That  information  can  be  secured  from  previous  comraiable 
systems  in  which  similar  or  identical  tasks  have  been  timed,  or  from 
the  body  of  general  human  performance  data  in  the  literature.  Neither 
of  these  two  sources  is  especially  available. 
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The  following  information  should  be  set  down  by  the  Human  Factors 
specialist  for  each  task: 

(1)  The  time  in  minutes  from  the  start  of  a  mission  segment,  at 
which  a  given  output  is  required.  This  may  also  be  expressed 
as  a  tolerance  range,  "not  earlier  than,"  "not  later  than"... 

(2)  The  time  duration  of  the  task  in  minutes 

(3)  The  maximum  time  permitted  by  system  requirements  for  the 
task  to  be  accomplished 

(4)  Notes  as  to  whether  a  given  task  is  self-paced,  machine -paced 
or  paced  by  other  task  requirements.  These  notes  may  suggest 
the  manner  in  which  a  redesign  of  the  task  is  possible. 

Task  duration  data  also  serve  as  inputs  to  the  development  of  time 
line  analysis  (PRD  Input  ZG)  and,  hence,  are  useful  in  the  determination 
of  job  positions. 

Table  XXV  is  an  illustration  of  a  task  duration  analysis  for  the 
"asse..  ble  missile"  segment  of  SM-X  operations. 
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TASK  DURATION  ANALYSIS  FOR  SM - 


second  technician 


PRD  INPUT  2F:  TASK  DIFrTC UL T Y /ERROR  LIKELIHOOD 


The  Human  Factors  specialist  is  especially  concerned  about  task  diffi¬ 
culty  because  this,  in  turn,  may  lead  to  a  higher  error  probability  with 
its  attendant  effects  on  mission  accomplishment.  Task  difficulty  arises 
because  system  requirements  are  incompatible  with  and  overload  the  skill 
capability  of  the  manpower  assigned  to  perform  the  task. 

Task  difficulty  is  not  the  same  as  error  likelihoc  d.  A  difficult  task 
need  not  automatically  have  a  higher  error  probability,  if  personnel  of 
higher  skill  are  available  to  compensate  for  the  increased  task  difficulty. 
The  significance  of  task  difficulty  is  intensified  when  the  task  is  also 
critical  to  the  accomplishment  of  the  mission.  Such  difficult-critical 
tasks  automatically  demand  redesign  because  their  attendant  error  prob¬ 
ability  cannot  be  accepted.  As  in  the  case  of  maximum  task  durations, 
which  the  operator's  performance  cannot  meet,  it  may  be  necessary  to 
automate  the  performance  of  the  task,  relax  the  accuracy  requirement 
(thus  implicitly  accepting  a  higher  error  probability)  or  redesign  the 
task  to  simplify  it. 

The  determination  of  task  difficulty  must  be  made  by  analyzing  the 
individual  task  in  terms  of  the  inputs  which  initiate  the  task  (e.g.  , 
verbal  message)  and  the  outputs  which  accomplish  the  task  (e.g.  ,  switch 
action).  The  Human  Factors  specialist  will  look  for  the  following 
characteristics  which  may  (not  necessarily  will)  indicate  an  excessively 
difficult  task: 

(1)  The  input  which  initiates  task  requires  excessively  precise 
visual  discriminations  or  fine  motor  responses 

(2)  The  operator's  response  to  the  initiating  inputs  roust  be  per¬ 
formed  so  quickly  that  he  has  problems  in  keeping  up  with  the 
initiating  inputs 

(3)  The  accuracy  demanded  of  the  operator  in  responding  to  the 
initiating  inputs  is  excessive  (e.  g.  ,  heading  erro"  must  be  with¬ 
in  0.  5  degrees) 

(4)  The  task  must  be  coordinated  extremely  precisely  with  other 
tasks  performed  by  other  personnel 

(5)  The  environment  in  which  the  task  must  be  performed  tends  to 
degrade  task  performance  (e.g.  ,  high  noise  levels,  acceleration). 
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(6)  Information  from  multiple  sources  (e.g. ,  several  displays, 

on  a  control  panel)  must  be  integrated  by  the  operator  in  order 
to  make  a  decision 

(7)  The  amount  of  information  available  on  the  basis  of  which  a 
decision  must  be  made  or  an  action  taken  is  less  than  desirable 

(8)  The  task  is  composed  of  may  sub- task  elements,  the  correct 
performance  of  all  of  which  is  necessary  to  task  performance, 
but  the  amount  of  feedback  provided  (knowledge  of  correctness 
or  incorrecfoess  of  sub-task  accomplishment  )  is  inadequate 

(9)  Short-term  memory  requirements  for  task  performance  are 
excessive  (e.  g. ,  memory  for  long  sequences  of  target  coord¬ 
inates) 

The  design  solutions  available  for  reducing  task  difficulty  include: 

(1)  Additional  training  provided  or  selection  of  higher  skilled 
personnel 

(2)  Simplification  of  the  task  by  such  means  as  combining  informa¬ 
tion  sources,  providing  additional  feedback,  subdividing  the  task 
among  several  operators,  changing  the  manner  in  which  the  task 
must  be  performed,  etc. 

(3)  Reducing  system  requirements  by  accepting  a  higher  error 
probability,  longer  response  time,  etc. 

The  task  analysis  provided  to  subjects  of  this  study  in  Session  4 
(Appendix  I)  contains  sample  difficulty  levels  which,  when  applicable, 
should  be  included  in  task  descriptions  in  the  PTDP,  RFP  and  SOW. 

Error  likelihood  has  been  discussed  in  connection  with  PRD  Input 
2D  (Task  Criticality). 
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PRD  INPUT  2G:  TIME-LINE  ANALYSIS 


The  time-line  analysis  (TLA)  presents  major  functions  and/or  tasks 
(depending  on  the  level  of  analytic  detail  included  in  the  TLA)  in  terms 
of  the  time  required  to  perform  the  functions/tasks  and  the  combination 
of  personnel  necessary  to  successfully  complete  the  functional  require¬ 
ments  of  the  system.  Figures  9  and  10  of  Appendix  I  present  examples 
of  the  TLA. 

A  TLA  for  major  (top-level)  functions  must  be  available  as  part  of 
the  backup  data  for  the  system  description  in  the  PTDP,  A  TLA  for 
major  tasks  must  be  part  of  the  backup  data  presented  as  part  of  the 
RFP/SCJWT 

The  TLA  provides  more  detailed  task  sequencing  and  interrelation¬ 
ship  data  than  the  personnel  functional  flow  diagram  (although  the  latter 
has  its  own  uses  and  should  not  be  replaced  by  the  former).  The  TLA 
may  have  implications  for  design  when,  for  example,  the  analysis  in¬ 
dicates  that  workplace  configuration  must  be  considered  to  accommodate 
several  people  working  in  the  same  area;  or  where  communications  or 
other  signaling  equipment  may  be  required  for  interaction  among 
personnel. 

The  TLA  may  indicate  points  in  the  mission  sequence  where  the  timing 
of  events  is  so  critical  that  the  ability  of  the  operator  to  respond  quickly 
enough  may  impose  a  delay  which  could  jeopardize  mission  success;  con¬ 
sequently,  the  operational  sequence  may  have  to  be  modified  or  the  means 
of  implementing  the  sequence  may  have  to  be  automatized.  All  of  this  is 
in  addition  to  its  other  primary  function  in  helping  to  indicate  the  number 
of  personnel  required,  which  also  has  its  impact  upon  design. 


PRD  INPUT  ZH:  POSITION  DESCRIPTIONS 


The  position  description  describes  the  functions  and  tasks  to  be 
performed  by  each  category  of  personnel  to  be  assigned  to  this  system 
crew.  It  is  a  summary  cf  the  available  information  concerning  what 
must  be  performed  by  the  individual  in  the  individual  job  position. 

A  major  element  in  the  position  description  will,  therefore,  be  the 
task  lists  and  descriptions  described  previously.  Skill  requirements 
for  the  position  and  the  training  to  be  provided  to  the  individual  per¬ 
forming  the  job  should  also  be  noted.  The  maximum  number  of  per¬ 
sonnel  who  will  fill  that  job  position  should  also  be  indicated. 

Preliminary  job  descriptions  should  be  available  in  the  PTDP  and 
more  detailed  descriptions  should  be  provided  in  the  RFP/SOW,  al¬ 
though  many  of  the  elements  of  the  information  will  be  available  earlier 
than  at  these  times,  of  course. 

The  design  implications  to  be  inferred  from  the  position  description 
are  those  which  have  been  described  earlier  as  being  implied  by  the 
task  data,  e.  g. ,  lists  of  tasks,  characteristics  of  those  tasks  and  task 
interrelationships.  Beyond  this  the  position  description  does  not  have 
a  major  potential  impact  upon  the  system  configuration. 


PRD  INPUT  3:  NUMBER  OF  PERSONNEL  PERMITTED 


The  number  of  personnel  permitted  in  the  operational  crew  described 
in  terms  of  individual  job  positions,  (e.g. ,  three  radar  maintenance 
mechanics),  should  be  made  available  to  the  design  engineer  in  the  FTDP. 
This  is  phrased  as  a  requirement,  not  as  a  recommendation,  although  it 
will  probably  be  the  result  of  a  compromise  with  the  system  engineer. 

The  number  of  personnel  specified  must  be  a  maximum,  for  two 
reasons:  First,  one  wishes  to  have  no  more  than  the  minimum  number 
of  personnel  needed  to  do  the  job;  second,  a  maximum  (not  to  be  exceeded) 
figure  acts  as  a  constraint  on  the  designer  by  implying  that  any  design 
concept  requiring  the  services  of  additional  personnel  will  not  be  satis¬ 
factory.  A  minimum  figure  (i.  e. ,  at  least  this  number  of  personnel  will 
be  required)  will  not  act  as  a  design  constraint,  since  with  a  minimum, 
the  engineer  is  permitted  to  design  for  any  upper  limit  he  wishes. 

The  following  is  an  example  of  an  acceptable  personnel  requirement: 
"The  contractor  shall  design  and  develop  the  propellant  transfer  sub¬ 
system  few  operation  and  maintenance  by  a  maximum  of  six  Air  Force 
personnel  (1  Fuel  Supply  Officer,  2  Fuel  Specialist/ supervisors,  3 
Liquid  Fuel  Systems  Maintenance  Specialist /Technicians).  Design  doc¬ 
umentation  shall  be  provided  to  verify  that  the  subsystem  can  be  operated 
and  maintained  by  this  structure. " 

This  input  (number  of  personnel)  is  derived  from  the  task  analysis  and 
time-line  analysis.  Determining  the  number  and  type  of  tasks  and  their 
distribution  over  time  (overlap  of  operations)  indicates  the  number  of  per¬ 
sonnel  needed. 

The  total  number  of  personnel  permitted  directly  affects  the  amount 
of  automation  required.  With  a  certain  minimum  number  of  personnel 
recourse  must  be  had  to  automatixa tion  (this  is,  of  course,  not  the  only 
or  even  the  primary  reason  why  one  automates,  but  number  of  personnel 
can  be  a  significant  factor  in  automation).  Obviously,  certain  functions 
cannot  be  performed  by  personnel  when  the  number  of  personnel  is  re¬ 
duced  beyond  what  the  engineer  considers  a  minimum  for  manual  opera¬ 
tion.  It  is  unnecessary  for  the  per  Brunei  specialist  to  make  specific 
design  recommendations  when  he  imposes  this  requirement,  but  he  must 
be  aware  of  its  design  consequences  (and  in  any  event  the  engineer  will 
make  him  aware  of  them).  Therefore,  this  requirement  should  not  be 
imposed  lightly. 
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Design  Implications 

(1)  For  automation.  Certain  system  functions  cannot  be  performed 
with  a  given  number  of  personnel  without  automat*  sing  these 
functions.  If  the  number  of  personnel  is  small  enough,  com¬ 
plete  automation  may  be  necessary.  Once  automation  is 
accepted  in  principle,  many  design  modifications  specific  to 
individual  equipments  may  result. 

(2)  For  system  operating  procedure r.  A  smaller  number  of  per¬ 
sonnel  may  require  that  functions  be  performed  serially  rather 
than  concurrently,  which  means  that  overall  mission  time  may 
be  stretched  out. 


PRD  INPUT  4:  SKILL  LEVEL  DESCRIPTIONS 


This  information  should  be  provided  in  at  least  general  form  in  the 
PTDP,  and  in  specific  detailed  form  in  the  RFP/SOW,  The  determin¬ 
ation  of  skill  level  and  the  provision  of  this  information  following  the 
start  of  design  is  of  little  value  to  the  system  engineer. 

An  adequate  definition  of  skill  level  is  extremely  difficult  to  provide. 
Its  behavioral  dimensions  are  quite  obscure.  Consequently,  the  design 
engineer  has  great  difficulty  in  understanding  the  implications  of  this 
parameter. 

Two  types  of  skill  level  descriptions  exist: 

(1)  Skill  required  by  the  task 

(2)  Skill  expected  to  be  made  available  as  a  result  of  training  or 
selection.  The  former  is  what  is  referred  to  commonly  as  the 
skill  level  description.  The  latter  is  actually  proficiency. 

For  optimal  system  performance,  the  two  levels  should  exactly 
balance  out  in  the  completed  system. 

Skill  level  appears  to  contain  the  following  dimensions  which  are 
inversely  related  to  the  amount  of  skill  required: 

(1)  Amount  of  supervision  required  (least  and  most) 

(a)  Highest  skill  level  is  represented  by  the  operator's  ability 
to  perform  all  tasks  (critical  or  not)  without  supervision 

(b)  Performance  of  all  critical  tasks  under  supervision;  all 
other  tasks  performed  without  supervision 

(c)  Performance  of  major  tasks  under  supervision;  all  routine 
tasks  performed  without  supervision 

(d)  All  tasks  must  be  performed  under  supervision 

(2)  Error  probability;  high  error  probabi’ity  indicates  that  the  task 
demands  high  skill 

(3)  Need  for  performance  aids,  e.  g.  ,  checklists 

(4)  Slow  response  time  by  the  operator 

(5)  Task  demands  imposed  upon  the  operator.  These  demands  may 
be  scaled  on  a  continuum  of  decision  and/or  perceptual -motor 
complexity,  e.g.  ,  more  complex  decisionr  in  the  task  require 
higher  skill  level 
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The  skill  level  description  should  be  phrased  in  terms  of  the  specific 
tasks  to  be  performed  by  personnel  in  operating  the  system  to  be  designed. 
Hence,  the  adequacy  of  the  skill  level  description  is  partially  dependent 
on  the  detail  in  the  task  description: 

A  sample  skill  level  requirement  might  be  phrased  as  follows:  "  Hard¬ 
ware  design  shall  be  accommodated  to  the  following  skill  level  require¬ 
ments,  The  skill  level  of  the  five -level  fuel  maintenance  specialist  to 
be  assigned  to  the  _  system  will  permit  him  to  perform  the  fol¬ 

lowing  tasks  without  supervision: 

(1)  Capable  of  hooking  up  flex  hoses  connecting  railroad  cars  to  the 
ground  supply  area 

(2)  Opening  and  closing  manual  hand  valves  in  accordance  with 
written  checklists 

(3)  Monitoring  propellant  flow 

(4)  Visual  inspections  of  piping  ("leak  checks") 

Under  supervision  to  perform: 

(1)  Calibration  of  flow  meters  and  associated  instrumentation 

(2)  Purge  and  drain  propellant  lines 

The  five  level  fuel  maintenance  specialist  is  not  qualified  to  perform 
any  troubleshooting  or  diagnostic  maintenance  tasks." 

Skill  level  does  not  have  (presently  because  of  lack  of  appropriate 
research)  direct  design  implications.  In  other  words,  one  cannot  directly 
convert  a  given  skill  level  into  a  particular  set  of  design  characteristics. 
However,  the  following  should  be  pointed  out  to  the  engineer: 

(1)  A  high  skill  requirement  and/or  a  low  level  of  expected  skill 
requires  the  provision  of  greater  positive  feedback,  more  inter¬ 
locks  (if  applicable),  fewer  combined  displays,  relatively 
invariant  and  slower  procedures,  more  checks  to  verify  progress, 
etc. 

(2)  As  related  to  number  of  personnel,  a  lower  skill  level  expected 
may  require  additional  personnel  backup,  but  this  has  not  yet 
been  demonstrated 


-  227  - 


PRD  INPUT  5:  TRAINING 


The  training  requirement  specifies: 

(1)  Length  of  time  training  will  be  provided 

(2)  Type  of  training,  e.  g. ,  for  particular  job  positions 

(3)  Degree  of  proficiency  to  be  achieved  after  training,  phrased 
as  an  expected  or  available  skill  level 

This  information  should  be  provided  in  preliminary  form  as  a  firm 
system  requirement  to  the  engineer  in  the  PTDP  and  further  refined  in 
the  RFP/SOW.  Once  equipment  design  has  begun,  this  information  is  of 
no  value  to  tae  design  engineer. 

The  type  of  training  and  particularly  the  expected  proficiency  level 
should  be  specified  in  terms  of  the  same  system  operations  used  as  part 
of  the  skill  level  description.  Definition  of  the  type  of  training  to  be 
provided  in  terms  of  f»  net  ions  only  is  not  satisfactory. 

Training  has  design  implications  only  in  terms  of  proficiency  {achieved 
skill  level).  The  design  implications  are  the  same  as  those  of  skill  level. 
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pr  D  INPUT  6:  PERSONNEL  AVAILABILITY 


This  input  refers  to  knowledge  of  those  personnel  already  in  the  Air 
Force  inventory  who,  upon  the  deactivation  of  a  system  similar  to  the 
one  being  developed,  w ill  become  available  to  man  the  new  system. 

This  information  is  needed  by  the  Air  Force  as  one  of  its  tradeoff 
criteria  for  the  specification  of  skill  levels  to  be  included  in  the  RFP 
and  SOW.  If  highly  skilled  personnel  in  particular  job  cate  tjories 
become  available  in  time  to  man  the  new  system,  the  procuring  agency 
will  be  able  to  specify  as  a  design  requirement  to  the  contractor  ♦hat 
the  system  should  bt,  designed  to  that  particular  skill  level  at  these 
categories.  The  nonavailability  of  personnel  with  the  particular  cap¬ 
abilities  required  by  the  new  system  may  or  may  not  cause  procur¬ 
ing  agency  to  require  that  system  to  be  designed  for  relatively  unskilled 
personnel  (depending  on  the  amount  of  training  it  is  prepared  to  provide 
inexperienced  personnel). 

In  this  way,  personnel  availability  aids  in  the  specification  of  manpower 
requirements.  The  design  engineer  is,  of  course,  primarily  interested 
in  the  specification  of  the  manpower  needed  by  the  new  system  (quite  apart 
from  their  availability  in  inventory)  but  the  description  of  the  kinds  of 
personnel  who  will  be  available  to  him  (e.g. ,  maintenance  mechanic,  four 
years  experience/such  and  such  a  system)  will  give  him  a  clearer  picture 
of  whom  he  should  design  for.  The  absence  of  a  personnel  availability 
statement  will  not,  however,  necessarily  reduce  design  effectiveness, 
if  the  new  system's  manpower  requirements  (regardless  of  personnel 
availability)  are  described  in  detail. 

Before  determining  personnel  availability,  it  is  necessary  for  the 
procuring  agency  to  know  in  advance  what  job  positions  must  be  filled 
for  the  new  system.  This  information  is  derived  from  the  preceding 
function/task  analyses.  Using  these  job  positions  as  criteria,  it  can 
then  examine  personnel  in  its  inventory  projected  over  system  develop¬ 
ment  time  to  determine  the  types  of  AFSCs  which  will  become  available 
to  match  the  tew  system's  manpower  requirements.  This  kind  of 
prediction  is,  of  course,  highly  risky,  since  experience  has  shown  that 
operational  systems  (and  the  personnel  they  employ)  do  not  always  be¬ 
come  obsolete  and  available  when  anticipated.  Should  it  be  possible 
to  include  a  statement  of  personnel  availability  in  the  potential  contractor's 
RFP,  it  should  be  in  as  much  detail  as  that  required  by  PRD  Inputs  3  and 
4.  In  particular,  skill  levels,  amount  of  previous  experience  and  amount 
of  additional  transition  training  to  be  provided  should  be  specified  in  the 
pefsomel  availability  statement.  In  addition,  available  AFSCs  should  be 
equated  with  the  job  positions  required  by  the  new  system. 
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PRD  INPUT  7:  PERSONNEL /EQUIPMENT  ANALYSIS 


The  Personnel /Equipment  Analysis  (P/F.  A)  is  not  a  specific  PRD 
input  to  the  engineer.  Each  time  the  personnel  specialist  submits  a 
memorandum  to  the  engineer  interpreting  a  PRD  input  in  terms  of  its 
design  implications  or  reviewing  an  equipment  design  against  system 
personnel  requirements,  he  is  engaging  in  P/E  A.  Hence,  the  P/E  A 
is  not  specific  to  any  particular  developmental  stage  or  PRD  input 

The  P/E  A  should  contain  the  following  elements: 

(1)  Statement  of  the  personnel  requirement,  e.  g.  ,  number  of 
personnel,  skill  level,  etc. 

(2)  The  implications  of  the  personnel  requirement  for  design, 
i.  e.  ,  what  should  be  done  to  meet  the  requirement  in  the 
form  of  changed  equipment,  procedures,  etc. 

(3)  Alternative  ways  of  meeting  the  requirement 

(4)  Recommended  design  actions 

{5)  Review  of  equipment  design  and  the  relationship  of  that 
design  to  the  personnel  requirement 


PRD  INPUTS  FOR  PTDP 


The  following  PRD  input*  should  be  inserted  into  the  PTDP.  Note 
that  this  list  includes  only  those  inputs  which  are  presumed  to  affect 
tne  system  configuration. 

(1)  Lists  of  tasks 

(2)  Preliminary  detailed  task  descriptions 

(3)  Time-line  analysis 

(4)  Personnel  functional  flow  diagram 

(5)  Preliminary  position  descriptions 

(6)  Number  of  personnel  required  (overall  crew) 

(7)  Skill  level  requirements  for  job  position  categories 

(8)  Preliminary  training  requiremento 

Backup  mission/events  analytic  data,  e.  g.  ,  mission  profile  and 
system  functions,  are  included  in  the  system  description  and  in  the 
summary  of  operations  and  maintenance  requirements.  Thj  design 
implications  of  the  PRD  inputs  will  also  be  included  in  the  PTDP. 

Other  PRD  inputs  which  are  not  of  specific  interest  tc  the  design 
engineer  will  be  included  in  the  personnel  package,  e.g.  ,  training  plans, 
training  planning  information. 
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PRD  INPUTS  FOR  RFP/SOW 


The  RFP/SOW  will  include  all  PRD  inputs  included  in  the  PTDP  plus 
the  following: 

(1)  More  detailed  task  descriptions 

(2)  Designation  of  critical  tasks 

(3)  Maximum  number  of  personnel  required  for  individual  job 
positions 

(4)  Skill  level  descriptions  keyed  to  individual  tasks 

(5)  Length,  type  of  training  and  proficiency  achievable  for  each 
job  category 
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11.  »HTR*CT 


The  purpose  of  this  study  was  to  determine  the  effect  on  system  design  of  using  man¬ 
power  requirements  (MR)  and  personnel  resources  data  (PRD)  as  design  requirements. 
Equipment  and  personnel  inputs,  e.g. ,  quantity  and  skill  level  of  manning  and  task 
information,  were  presented  incrementally  to  six  design  engineers  in  a  simulation  of 
the  Phase  1A/1B  development  of  the  Titan  III  propellant  transfer  and  pressurization  sub¬ 
system.  Subjects  were  required  to  create  a  complete  subsystem  design,  including 
schematics,  equipment  descriptions,  drawings  and  bills  of  material.  Cost  effective¬ 
ness  measures  were  applied  to  the  data.  It  was  found  that  manpower  requirements  and 
PRD  inputs  do  influence  the  equipment  configuration,  but  only  moderately,  because 
equipment  design  proceeds  so  rapidly  that  incremental  PRD  inputs  inevitably  lag  design. 
Engineers  are  responsive  only  to  inputs  which  are  framed  as  desigr  requirements  and 
which  can  be  interpreted  in  design-relevant  terms.  Engineers  were  found  to  be  gen¬ 
erally  indifferent  to  personnel  considerations.  The  results  of  the  study  indicate  that 
if  personnel  factors  are  to  be  incorporated  into  design,  it  is  necessary  to  supply  PRD 
inputs  as  design  requirements  to  the  engineer  in  his  initial  statement  of  work.  The 
analyses  upon  which  MR  and  PRD  inputs  are  based  must  be  performed  prior  to  the 
issuance  of  a  Request  for  Proposal  and  not  oelegated  to  a  development  contractor. 
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